AviSynth 2.5.6 RC 2 Release Candidate [October 7th]

[Arachnotron]

Can someone with a 3DNow capable processor please test the following script

Sounds ok on my Athlon XP 1800+/Asus A7N8X

[Manao]

IanB : Impressive ! the changes you made in the cache seems to work : the script i PMed you some times ago is now functionning as expected The speed gain on this particular script is awesome ( from 6 fps to 14 fps )

[tritical]

IanB, I have a question about something in cache.cpp... this might be dumb so bear with me, but I'm wondering about what is happening. This code inside Cache::GetFrame, for the h_policy == CACHE_NOTHING handling:

  if (h_policy == CACHE_NOTHING) { // don't want a cache. Typically filters that only ever seek forward.
	__asm mov ebx,ebx  // Hack! prevent compiler from trusting ebx contents across call
    PVideoFrame result = childGetFrame(n, env);
    if (result->vfb) env->ManageCache(MC_ReturnVideoFrameBuffer, result->vfb);
    return result;
  }

Won't the call to env->ManageCache() to return the vfb cause the caches of filters that use CACHE_ALL around a filter that uses the CACHE_NOTHING policy to have frames dropped from their lists that shouldn't necessarily be dropped? I've been testing this script:

mpeg2source()
tfm()
tfmpp()
tdecimate()

while allowing tfm/tfmpp/tdecimate to default to CACHE_ALL, and that one works perfectly. However if I add in a filter that uses CACHE_NOTHING like this:

mpeg2source()
tfm()
tfmpp()
avstimer() <= uses CACHE_NOTHING
tdecimate()

now the caches before tdecimate and tfmpp only store 2 frames in their lists which results in an awful lot of the getframe calls from tdecimate needing frames to be redone from tfm on up.

If I comment out that line from above, or set tfm/tfmpp/tdecimate to use a CACHE_RANGE policy then everything works fine.

[Mug Funky]

Users with P3 should test the following script:

it loads (no vanishing)

i get a 1k tone going between left and centre of the stereo field every second or so. that what you're expecting?

there's no (audible) distortions in the tone, so i'm going to assume the conversions all maintain their integrity.

[edit]

Can someone with a 3DNow capable processor please test the following script

my p3 makes a sound like a buzz. opening the avs in audition (cool! i didn't realise you could do that without an avi wrapper) reveals the positive clipping at negative fullscale, as you said.

[Arachnotron]

my p3 makes a sound like a buzz. opening the avs in audition (cool! i didn't realise you could do that without an avi wrapper) reveals the positive clipping at negative fullscale, as you said.

Ok, I misunderstood the purpose

On my 3Dnow! capable athlon, the script results in clipping, just as I suppose it should. I loaded the script in vdub and saved a short .wav, which I loaded in audacity. Here is a screendump from a zoomed-in sinus.

[edit]sinus.. er... sine

[Mug Funky]

ah! yours is doing the right thing then. mine's flipping the positive clips to the negative side. as you can imagine it sounds pretty bad

[Leak]

Originally posted by IanB
- Reworked Cache and memory management
Please break out your most evil cache busting scripts and test, test and test more.

Since you seem to be quite informed when it comes to the cache now, could you (or whoever is well-versed on the topic) perhaps add a bit of documentation for SetCacheHints on AviSynth.org, or how caching works in general?

I guess I'm not the only one here that doesn't really understand it fully, and I guess a reduction of unneeded caching of frames that don't need to be cached can only be beneficial, performance-wise.

np: Panasonic - Rutina (Kulma)

[IanB]

@Arachnotron, @Mug Funky,

Thanks guys for the tests (and the screen grab). It's a relief knowing I didn't stuff up the 3DNow code. Not being able to test code paths is a real downer.

@Manao,

Nice to know it make some difference. Your original case was caused by exceeeeedingly long cache chains all pointing at a small number of valid, inuse, VFB's.

@Leak,

Yeah I probably will knock up some info when I get all the bits and pieces integrated. I'm also trying to force myself to write lots of comments in the source.

Originally posted by tritical
IanB, I have a question about something in cache.cpp. I'm wondering about what is happening. This code inside Cache::GetFrame, for the h_policy == CACHE_NOTHING handling:

if (h_policy == CACHE_NOTHING) { // don't want ...
  _asm mov ebx,ebx  // Hack! prevent compiler ...
  PVideoFrame result = childGetFrame(n, env);
  if (result->vfb)
    env->ManageCache(MC_ReturnVideoFrameBuffer, result->vfb);
  return result;
}

Won't the call to env->ManageCache() to return the vfb cause the caches of filters that use CACHE_ALL around a filter that uses the CACHE_NOTHING policy to have frames dropped from their lists that shouldn't necessarily be dropped?
...
while allowing tfm/tfmpp/tdecimate to default to CACHE_ALL, and that one works perfectly. However if I add in a filter that uses CACHE_NOTHING like this:

I assume you actually have this setup, 2 x avstimer, coz only 1 is useless. I have also marked in the cache instances for clarity.

mpeg2source()
-> cache  <= CACHE_ALL
tfm()
-> cache  <= uses CACHE_NOTHING
avstimer()
-> cache  <= CACHE_ALL (maybe absent)
tfmpp()
-> cache  <= uses CACHE_NOTHING
avstimer()
-> cache  <= CACHE_ALL (maybe absent)
tdecimate()
-> cache  <= CACHE_ALL

now the caches before tdecimate and tfmpp only store 2 frames in their lists which results in an awful lot of the getframe calls from tdecimate needing frames to be redone from tfm on up.

If I comment out that line from above, or set tfm/tfmpp/tdecimate to use a CACHE_RANGE policy then everything works fine.

Yeap, full points for a bug find.

Avstimer() is a special case, Crop(), etc, are all in the same boat, in that they pass VFB's straight thru unmodified. By telling the cache below it CACHE_NOTHING, that cache dutifully returns all the associated VFB's to the tail of the queue for early reuse. Now when the cache above gets that same PFrame, it's VFB it has already been returned, and will get reused pdq. I think I will be taking that out in the next cut, I need to design a definative way to know a VFB is really unloved before I return it.

CACHE_RANGE is a lot more aggressive with it's VFB members, it actually bump's their use count while they are in scope, this has 2 effects. a) the VFB can't be stolen, b) all calls to MakeWritable() return a copy (and cost a blit). I tried this logic generally and it can cause severe memory shortage. 640x480 YUY2 VFB's are 600kb each, locking 7 buffers (radius 3) is 4.2Mb per cache instance, 24 cache instances (effectively script lines) and there's 100Mb. And the performance is not as good when strange things are not happening.

IanB

[scharfis_brain]

restore24 is not working anymore correctly with AVS 2.5.6 beta1.
(it produces jerky motion and lets blends sneak thru)

but restore24 works very nice using the predecessor, AVS 2.5.6 alpha 19-12-2004

might this be a problem of smartdecimate?
smartdecimate prooved being not very stable in past, unfortunately. but sadly this new AVS-version seems to broke everthing.


I will test this more tomorrow with some minor complex scripts.

[IanB]

Originally posted by scharfis_brain
restore24 is not working anymore ...

Got a current link to it, the "Gleitz" link I have say "Not Found" (I think it does, mien Deutch ist nicht zehr gut)

IanB

[Boulder]

I UL'd it here : http://www.saunalahti.fi/sam08/restore24.rar

[scharfis_brain]

updated package here
http://forum.gleitz.info/attachment....chmentid=70159

I still need to test in a less complex environment.
Restore24 is way too complex....

[Wilbert]

I got a report from the german forum that SeparateFields separate the fields of field-based material, although it shoudn't do anything. This is indeed the case with the latest binary. I will look at it.

[stickboy]

neuron2 and I have been complaining about that inconsistency between SeparateFields() and Weave() for a long time.

Now, should SeparateFields() on a field-separated clip be a no-op, or should it generate an error? (And likewise, should Weave() on a non-field-separated clip be a no-op, or should it be an error?)

I'm leaning toward error, especially if you're going to be changing behavior that might affect existing scripts.

[Wilbert]

Yes, perhaps it's good to give an error. Saying that you should apply AssumeFrameBased before applying SeparateFields to field-based material.

I didn't check Weave. Does it also do something on frame-based material?

[IanB]

Sh0dan drop the test for already IsFieldBased() between revs 1.4 and 1.5 in the old 2.x branch (prior to the big file shuffle)

My vote is for "errors" when it's inconsistant, i.e. can only Weave() something that IsFieldBased()==True, can only SeparateFields() something that IsFrameBased()==True.

@Wilbert

On IsFrameBased() material :-

DoubleWeave() goes thru some motions and produces 1 same frame and 1 field offset frame.

Weave() goes thru the same motions as above but appears to do nothing. Remember Weave() is implemented as DoubleWeave().SelectEven()

IanB

[Wilbert]

Weave() goes thru the same motions as above but appears to do nothing. Remember Weave() is implemented as DoubleWeave().SelectEven()

Hmm. That complicates it a bit, because DoubleWeave handles field-based and frame-based material. Do you know whether it is possible to throw an exception anyway (using Weave on frame-based material)?

btw, there's still a bug in DoubleWeave and YV12.

[IanB]

Originally posted by Wilbert
Hmm. That complicates it a bit, because DoubleWeave handles field-based and frame-based material. Do you know whether it is possible to throw an exception anyway (using Weave on frame-based material)?

Just commited to CVS, Weave() enforces IsFieldBased(), SeparateFields() enforces IsFrameBased(), DoubleWeave() untouched. Now we wait to see what the native think.

btw, there's still a bug in DoubleWeave and YV12.

Fixed! Was missing offset calc code for Chroma, only had the Luma code.

IanB

[Wilbert]

About ShowFiveVersions

AviSource("F:\TestStreams\telecined-clip.avi") # YV12 clip
DoubleWeave()
a = Pulldown(0,2).Subtitle("0,2")
b = Pulldown(1,3).Subtitle("1,3")
c = Pulldown(2,4).Subtitle("2,4")
d = Pulldown(0,3).Subtitle("0,3")
e = Pulldown(1,4).Subtitle("1,4")
ShowFiveVersions(a,b,c,d,e)

resulted in a black clip (YUY2 mode works fine though).

[IanB]

Wilbert,

resulted in a black clip (YUY2 mode works fine though).

Most strange I cannot reproduce it.

Q1. Is the output fully black, including the 2 grey corner blocks, or just the 5 frame elements?

Q2. Is the subtitle text visible or is that black as well?

Q3. Does a SeparateFields() first change the behavior? (Test 1)

Q4. Does a convertToRGB32() (or YUY2) at the end change anything? (Test 2, 3)

Q5. Does a StackHorizontal(a, b, c) suffer the same fate as the Show5? (Test 4)

Q6. Does a YV12 BlankClip() clone behave the same? (Test 5)

Q7. What are you displaying this with? What YV12 display codec are you using? Is it Xvid or DivX? What is the final total width? Is it mod 16? Does a Crop help? (Test 5)

AviSource("F:\TestStreams\telecined-clip.avi") # YV12 clip
# BlankClip(Last, Pixel_type="YV12", Color=$56789A) # Test 5
# SeparateFields()         # Test 1
DoubleWeave()
a = Pulldown(0,2).Subtitle("0,2")
b = Pulldown(1,3).Subtitle("1,3")
c = Pulldown(2,4).Subtitle("2,4")
d = Pulldown(0,3).Subtitle("0,3")
e = Pulldown(1,4).Subtitle("1,4")
ShowFiveVersions(a,b,c,d,e)
# ConvertToRGB32()         # Test 2
# ConvertToYUY2()          # Test 3
# StackHorizontal(a, b, c) # Test 4
# Crop(0, 0, 640, 480)     # Test 6

IanB