View Single Post
Old 17th June 2008, 00:12   #2  |  Link
gzarkadas
Registered User
 
gzarkadas's Avatar
 
Join Date: Sep 2005
Location: 100011110010001000001 10000011111111000001
Posts: 221
@Gavino,

I see that you had time to test it seriously, congratulations .

I have verified the existence of this behavior (running avisynth 2.57) with the following script (a slight modification of your template):
Code:
# 100 frames black + 100 white, to give predictable luma
BlankClip(100, pixel_type="YV12")+BlankClip(100, pixel_type="YV12", color=color_white)
ScriptClip("SubTitle(String(current_frame), y=10)")
Trim(50, 149)
ScriptClip("""
  f1 = current_frame
  a1 = AverageLuma() # OK
  f2 = current_frame
  a2 = AverageLuma() # gives wrong value
  f3 = current_frame
  SubTitle("a1="+string(a1)+" a2="+string(a2), y=30) # shows a1 != a2
  SubTitle(String(f1)+","+String(f2)+","+String(f3), y=50)
""")
The problem occures because Trim is placed between the two runtime scripts and because runtime functions compute their values dynamically requesting frames at runtime.

The screenshots for frames 0, 49, 50 of final clip are attached.

The play of frames shows up at the result as following:
1. ScriptClip #2 requests a frame (0, 49, 50)
2. f1 is set to current_frame (0, 49, 50)
3. Calculation of a1 requests a frame from Trim (0, 49, 50)
4. Trim requests a frame from ScriptClip #1 (50, 99, 100)
5. ScriptClip #1 delivers the frame and prints its number on it (50, 99, 100)
6. f2 is now the value of last assignment to current frame (50, 99, 50). Last value is 50 because frame #100 has already been requested (at the linear, forward scan that I have applied to test) and the cache returns the frame without calling ScriptClip #1.
7. Calculation of a2 requests a frame from Trim (50, 99, 50, last is 50 because current_frame has not changed)
8. Trim requests a frame from ScriptClip #1 (100, 149, 100)
9. ScriptClip #1 delivers the frame and prints its number on it (100, 149, 100) but because its output at the 2nd AverageLuma call is not used as the script's output it does not show at the result
10. f3 is now the value of last assignment to current frame (100, 149, 50). Last value is 50 because frame #100 has already been requested (at the linear, forward scan that I have applied to test) and the cache returns the frame without calling ScriptClip #1.

This BTW confirms my speculation in the other thread you mention. Whether local, or global a scheme that depends on setting a single variable will show-up this behavior in such situations. I don't know if a remedy to this can be applied without incurring serious performance issues; your proposed solution intervenes with the normal way of operation of runtime filters, which is to set the current_frame. But for the time being, as we wait for the Avisynth devs to decide on this issue, one can use the following strategy to get the intended results in such situations:

1. Store the value of current_frame in a local variable of the runtime script before calling the runtime function.
2. Call the runtime function
3. Restore the value of current_frame by explicitly assigning to it the value stored at the local variable.
Attached Images
   
__________________
AVSLib, a free extension library for Avisynth. Current version: 1.1.0 (beta), 14/05/2007.
[ Home page | Download page ]
gzarkadas is offline   Reply With Quote