View Full Version : AviSynth 2.6.0 Alpha4 [Jan 14th, 2013]
Groucho2004
9th September 2013, 22:16
ColorBars()
#~ ConvertToYV24()
ScriptClip("return last")
I can't reproduce this with the given script. I loaded it into VDub and encoded also to HuffYUV. Memory usage settles at about 140K. OS is XPSP3.
Groucho2004
9th September 2013, 22:33
This is the crash script.
Script error: ScriptClip does not have a named argument "local"
StainlessS
9th September 2013, 22:37
@Martin53,
There is a known Overlay bug in v2.6a4, here:
http://forum.doom9.org/showthread.php?p=1624303#post1624303
Use Groucho2004's ICL Avisynth.dll with fixed OverLay for YV24. (just overwrite dll in sytem32/SysWOW64)
EDIT: Groucho, Local is for the GScript version Scriptclip. EDIT: Actually Grunt, not Gscript.
martin53
9th September 2013, 22:38
I can't reproduce this with the given script.
Did you remove the comment marks?
Groucho2004
9th September 2013, 22:43
Groucho, Local is for the GScript version Scriptclip.
Ah, I see.
martin53
9th September 2013, 22:44
Use Groucho2004's ICL Avisynth.dll
Please give me a hint where I find this dll.
Groucho2004
9th September 2013, 22:46
Please give me a hint where I find this dll.
Here you go. (http://forum.doom9.org/showthread.php?t=167358)
StainlessS
9th September 2013, 22:49
Groucho, see here for recent nasty little problem concerning GScript Local solution. EDIT: Actually Grunt, not Gscript.
http://forum.doom9.org/showthread.php?t=168538
martin53
9th September 2013, 22:49
yes, I did.
OK, I also rechecked in parallel and found after the 1st post that some of my experiments stabilized, so what I had assumed to be bad was not always. I always try to give a most simple example, but alas, that misleads me sometimes. Please look at my edit, but StainlessS already posted that it's not ConvertToYV24() alone, but together with Overlay() - as in my real problem script. So, if you'd be so kind to indicate where I can find the fixed dll, thank you!
martin53
9th September 2013, 22:52
Here you go.Many thanks!
Gavino
9th September 2013, 22:52
Local is for the GScript version Scriptclip.
Actually, it's from the GRunT version.
But I expect you can just leave out local=true as I doubt it has anything to do with the problem.
EDIT: Looks like you've now found the solution anyway.
StainlessS
9th September 2013, 22:53
OOooops, yes of course. :(
vcmohan
10th September 2013, 03:37
@stainless .Thanks. But I avoided the hassle by adding three calls in avisynth.h 2.5. IsY8() returning false, GetHeight/width subsampling returning 0 or 1. At parameter checking itself I ensure the input formats . In my plugin code I do not by name check any other Planar formats.
ultim
12th September 2013, 20:17
Hello, I've got another question about the alignment code, this time though it is purely technical and not ideological :)
In both NewVideoFrame and NewPlanarVideoFrame, assuming that we need a buffer of size large, the methods reserve size+align*4. For alignment only, size+align-1 is enough, so I was wondering if this overreserve is accidential, or it this on purpose and the align*4 is needed for some implementation detail that I was too stupid to spot.
Contextual information (rant): You might be thinking,"WUUT, this strange dude is still working on alignment?" Yes and no. Well, first of all I cannot allow myself to work on avisynth every day, so progress is steady, but slow. But more importantly, since my last questions about alignment in avisynth I have done a lot of magic (many-many hours) using Git's rebase to clean up my repository, in the hope that upstream (IanB) will accept my proposals this way, when I finally publish them. So that he'll get nice patches :) Now that I'm done, I'm continuing where I left off, which is (yeah you guessed right) alignment. It looks like I am reverting about 99.9% of my alignment patches, but I still like to understand things even if I don't modify them, which is why I'm asking the question in the beginning of this post. Cheers and thank you for your help!
IanB
12th September 2013, 22:54
The off hand answer is so you can run off the end safely with an sse load or store, but as you say size+align-1 would be sufficient. So I don't know, may be you can do some archaeology and find an answer. Here is a link to version 1.1 of Avisyntn.cpp, Thu Jul 4 13:16:41 2002 UTC (11 years, 2 months ago) by richardberg (http://avisynth2.cvs.sourceforge.net/viewvc/avisynth2/avisynth/avisynth.cpp?hideattic=0&revision=1.1&view=markup) as originally supplied by BenRG. Around version 1.9 Sh0dan started doing something with improving alignment.
ultim
13th September 2013, 18:49
The off hand answer is so you can run off the end safely with an sse load or store, but as you say size+align-1 would be sufficient. So I don't know, may be you can do some archaeology and find an answer. Here is a link to version 1.1 of Avisyntn.cpp, Thu Jul 4 13:16:41 2002 UTC (11 years, 2 months ago) by richardberg (http://avisynth2.cvs.sourceforge.net/viewvc/avisynth2/avisynth/avisynth.cpp?hideattic=0&revision=1.1&view=markup) as originally supplied by BenRG. Around version 1.9 Sh0dan started doing something with improving alignment.
Thanks IanB! I really appreciate you being here for us every day and helping us.
As for the reason of the memory allocation in question, I looked at the repository, but unfortunately, there is nothing there to answer me. In the initial checkin (first-ever version 1.1 of avisynth), where the supported alignment was only 8 bytes, the reserved extra space was already 32 bytes. So even here, farthest back in the history, we see that align*4 is used. "+32" was then refactored to "+align*4" in revision 1.12 (Mon Feb 10 16:42:40 2003), but even there, the commit only contains the unhelpful message of "Moved avisynth_2_1 onto MAIN".
"so you can run off the end safely with an sse load or store" cannot be the reason either, because the row pitch (which is calculated based on the alignment) already makes sure that such things cannot happen.
So I have no explanation for the current code right now, so I'm gonna try changing it to "+align-1", do some tests and see if anything breaks apart. My bet is that everything will still work as expected, but ofc it wouldn't be the first time for me to be wrong. :)
Wilbert
29th September 2013, 16:31
I moved all the posts about the fork of ultim to this thread: http://forum.doom9.org/showthread.php?t=168856
IanB
29th September 2013, 23:38
Next version, AviSynth 2.6.0 Alpha5 [Sep 18th, 2013]
Also a clickable link for the post above Avisynth forks
I wish link parsing could be re-enabled, in the meantime I wish people would manually do the tags themselves,
i.e. http://forum.doom9.org/showthread.php?t=168856
Richard1485
12th November 2013, 22:51
Did anyone get SoundOut to work with Avisynth v2.60a4? When i open a script (ending with SoundOut()) in Virtualdub i get the error message:
Avisynth open failure:
Cache: Filter returned invalid response to CACHE_GETCHILD_CACHE_MODE. 176310176
Is it supposed to work in 2.60 or is something not implemented properly?
Did you ever get SoundOut() to work? You mentioned that you might try to recompile the plugin. I receive the same error in v2.60a5. This page (http://avisynth.nl/index.php/SoundOut#Installation_and_Usage) says: "It will be included in AviSynth from v2.6 on", but I guess that that has not happened yet.
EDIT: It seems to work with Wavsource() but not other sources e.g. NicAC3Source(). With Wavsource() I can render to FLAC, but Virtualdub crashes when rendering AC-3.
ultim
13th November 2013, 09:07
Avisynth open failure:
Cache: Filter returned invalid response to CACHE_GETCHILD_CACHE_MODE. 176310176
This usually means the plugin needs to be updated to the 2.6 interface. Recompiling with the newest header should solve the issue.
Wilbert
13th November 2013, 19:15
Did you ever get SoundOut() to work? You mentioned that you might try to recompile the plugin.
Haven't tried yet. Will do so on Sunday.
Richard1485
13th November 2013, 19:20
Haven't tried yet. Will do so on Sunday.
Thanks. Now I know that I haven't overlooked an update to the plugin.
Gavino
13th November 2013, 21:13
SoundOut() works for me with 2.6a4.
Also worked for poisondeathray (post #100).
Does it always fail for you, Wilbert, or is it dependent on script contents?
I only tried a simple test - perhaps you need something which heavily exercises the audio cache to provoke the error?
EDIT: I notice now Jeff B above reports failure is source-dependent.
Wilbert
23rd November 2013, 20:25
Does it always fail for you, Wilbert, or is it dependent on script contents?
I only tried a simple test - perhaps you need something which heavily exercises the audio cache to provoke the error?
EDIT: I notice now Jeff B above reports failure is source-dependent.
I guess so, but i don't remember. A simple Tone() didn't work either. Anyway I managed to compile it finally: http://forum.doom9.org/showthread.php?p=1654982#post1654982. It was a bit more involved than ultim said since some header files were missing too among some other things. Let me know if there are any issues.
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.