View Full Version : Why would RT_AverageLuma complain about current_frame?
MrPete
5th January 2015, 03:39
I'm doing something I thought was quite basic:
AvgL = RT_AverageLuma(myclip,x=1900,y=0,w=10,h=10)
And no matter what I do, I get this error:
Avisynth open failure:
RT_AverageLuma: 'current_frame' only available in runtime scripts
I assume I'm making a noob error but having searched I can't find any help on this... I am guessing this is NOT a StainlessS problem...
So... HELP! :)
Thanks muchly,
Pete
StainlessS
5th January 2015, 11:11
current_frame is only available in runtime environment: http://avisynth.nl/index.php/Runtime_environment
eg ScriptClip, you can however give it a frame number, as it dont know what frame you are asking for.
n=frameNumber.
Prolog to runtime Luma funcs (about 60 lines before RT_Averageluma)
****************************************
******* MASKED Luma Y Functions ********
****************************************
Compile time/runtime functions, Planar, YUY2, RGB24 & RGB32. (RGB internally converted to YUV-Y).
The compiletime/runtime clip functions share some common characteristics:-
The 'n' arg is an optional frame number and defaults to 'current_frame' if not specified.
The x,y,w,h, coords specify the source rectangle under scrutiny and are specified as for Crop(), the default 0,0,0,0 is full frame.
If 'interlaced' is true, then every other line is ommited from the scan, so if eg y=1, then scanlines 1,3,5,7 etc are scanned,
if eg y=4 then scanlines 4,6,8,10 etc are scanned. The 'h' coord specifies the full height scan ie same whether interlaced is true
or false, although it will not matter if the 'h' coord is specified as eg odd or even, internally the height 'h' is reduced by 1
when interlaced=true and 'h' is even.
Matrix: Conversion matrix for conversion of RGB to YUV-Y Luma. 0=REC601 : 1=REC709 : 2 = PC601 : 3 = PC709,
Default = (Width > 1100 OR Height>600) then 3(PC709) else 2(PC601). YUV not used
The optional mask clip, governs which pixels are processed by the functions. Where a luma pixel in selected area of the the mask clip is
in range "MaskMin" to "MaskMax" inclusive, then those pixels will be processed. The Mask must also be Planar but not
necessarily the same colorspace as clip c, also must be same dimensions and have at least the same number of frames as clip c.
Calling without mask clip OR with MaskMin=0,MaskMax=255 will effectively ignore the mask and scan full x,y,w,h area.
RT_AverageLuma(clip c,int "n"=current_frame,int "delta"=0,int "x"=0,int "y"=0,int "w"=0,int "h"=0,bool "interlaced"=false,
int "Matrix"=(Width>1100||Height>600?3:2),clip "mask"=NOT_USED,int "MaskMin"=128,"MaskMax"=255)
Return int -1, if no valid pixels in Mask clip.
Returns FLOAT value average luma (0.0 -> 255.0) in frame(n+delta) for area x,y,w,h.
OK, Tested this time, (I've just woken up, Yawn)
Colorbars
n=1000
AvgL = RT_AverageLuma(n=n,x=width/2,y=height/2,w=10,h=10)
RT_SubTitle("Frame %d AverageLuma = %f",n,AvgL)
return last
Or
colorbars
ScriptClip("""
AvgL = RT_AverageLuma(x=Width/2,y=height/2,w=10,h=10)
RT_Subtitle("%d ] %f",current_frame,AvgL)
return last
""")
return last
MrPete
5th January 2015, 13:31
I think I'm about to understand something quite important... but not quite there yet.
OK... I get that ScriptClip etc are able to perform per-frame calculations during run time.
What then is the meaning of a NON runtime calculation, ie the normal AverageLuma(clip)?
StainlessS
5th January 2015, 13:51
AverageLuma() is also a runtime function, difference being that RT_ version will accept an optional n=framenum.
You can trick AverageLuma into doing same(making it think it is in runtime environment) by eg setting current_frame to a frame number.
EDIT:
Colorbars.ConvertToYV12 # AverageLuma Planar ONLY
current_frame=1000 # hoodwink AverageLuma : Try comment out this line
AvgL = AverageLuma() # No args (other than clip)
RT_SubTitle("Frame %d AverageLuma = %f",current_frame,AvgL)
return last
MrPete
5th January 2015, 14:09
Woah. My head is (temporarily) spinning.
So... what is actually happening when we do or do-not set current_frame???
Does touching current_frame somehow force the parsing engine to say something like "delay all following code until runtime"???
That sounds like a magic hidden side effect. Are there a lot of these?
StainlessS
5th January 2015, 15:15
During Frame serving, runtime filters eg ConditionalFilter(), ScriptClip() etc set current_frame for the functions 'inside' eg Scriptclip,
so they know what frame is current. A filter in the filter graph has a frame number requested by the following filter, etc etc, requested by
the viewer/player (or whatever), runtime functions are not in any filter graph and nothing will automatically do anything to them or request anything
from them unless you code it that way. Scriptclip (and the others) set current_frame to try to make that part easier for the script writer.
You need to read/re-read the manual many times over (just like the rest of us had to).
what is actually happening when we do or do-not set current_frame
Scriptclip etc set current_frame before doing an "Eval()" on the script 'inside' the Scriptclip string, and delete it after finished.
AverageLuma() tries to get the value of the variable named 'current_frame', and if it fails, assumes that it is not in the runtime
environment. If you set current_frame outside of the runtime environment, AverageLuma will simply assume that it is in the runtime environment,
and get AL for that frame.
Grunt also has an extension to the AverageLuma func (offset to current_frame I think, not sure, I dont ever use that when RT_AverageLuma exists).
current_frame is just an ordinary Global variable, nothing terribly special about it except that it magically appears and disappears at beginning and end of
runtime environment. Read about special variables Last and current_frame in link previously given (I think).
EDIT: Come to think of it, where we previously set "current_frame=1000" we were actually setting a non global var as we did
not use GLOBAL keyword. When AverageLuma calls func to get value of variable 'current_frame', the function looks up the Local Vaiable list first and if that fails then looks at the Global variable list (Locals 'hide' globals).
Gavino
5th January 2015, 19:12
current_frame is just an ordinary Global variable ...
In the standard Avisynth runtime, current_frame is a local variable.
GRunT changes this to a global variable, allowing run-time functions to work inside user functions called from a run-time script.
MrPete
5th January 2015, 19:53
Gavino, you're The Expert... over here (http://forum.doom9.org/showthread.php?p=1704739#post1704739) I asked if there's a way to (a) detect if a variable is global vs local, and/or (b) view the stack.
Any hope?
StainlessS
5th January 2015, 19:56
Thank you big G. I was about to correct that but was obliged to go to the pub, nice to see that life in the leper colony still affords you a little free time. :)
StainlessS
6th January 2015, 13:08
I'll see if I can implement a sort of RT_IsGlobal(), RT_IsLocal() type thing in next update to RT (NOT sure if its possible).
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.