Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Development

Closed Thread
 
Thread Tools Search this Thread Display Modes
Old 8th December 2013, 23:57   #401  |  Link
ultim
AVS+ Dev
 
ultim's Avatar
 
Join Date: Aug 2013
Posts: 359
A second bugfix release is available. Besides proudly wielding the version number "0.1 (r1555)", the most important changes are:
  • A fix for the autoload issue reported here.
  • A fix for TemporalSoften which potentially resulted in crash.
  • A fix for some filters not loading under specific circumstances. Discovered on WriteFileStart.
  • A fix for the "return" script statement not returning from the current function if used inside if/while/for etc.
This release is a nice opportunity for you to try out AviSynth+ if you didn't already. Unless some major issue pops up, the next release will bring larger changes.

There is a slight change in behavior in r1555, made necessary by the fix for the autoload issue. Previously, plugin autoloading started automatically if forced by the AutoloadPlugins() function, or if an unknown(=external) function was found. Beginning with this release there is also a third condition, autoloading will also happen if any LoadPlugin() is issued, and it will happen right before the LoadPlugin() is executed. This was necessary to preserve compatibility with scripts for classic AviSynth.

Anyway, enjoy our latest and greatest release. Download from the homepage.
__________________
AviSynth+
ultim is offline  
Old 9th December 2013, 00:36   #402  |  Link
ultim
AVS+ Dev
 
ultim's Avatar
 
Join Date: Aug 2013
Posts: 359
In other news, there is a GitHub organization now for AviSynth. If you're the developer of an open source plugin, script or utility related to AviSynth, join the organization so that all avs-related code can be found in one place. Of course you still preserve full admin privileges over your repository upon joining, but visitors will be able to find all AviSynth related projects at a glance, which is good for both your code, for AviSynth, and for the visitor/community.

If you're already a GitHub user, joining is easy, you just need to tell me or TurboPascal7 that you'd like to join, and let us know your GitHub username. If you're not using GitHub already, I strongly recommend you create an account. Not (only) because of the (1) organization, but because (2) it will greatly simplify accepting contributions from others (be it code or feedback), and (3) GitHub will also make it much easier for you to host your code and binary releases.

So, fellow Avs Devs, join the AviSynth organization on GitHub.
__________________
AviSynth+

Last edited by ultim; 9th December 2013 at 01:16.
ultim is offline  
Old 9th December 2013, 01:07   #403  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,431
Quote:
Originally Posted by ultim View Post
A fix for the "return" script statement not returning from the current function if used inside if/while/for etc.
I can understand why you might consider the old behaviour to be a bug, but I made GScript work that way because that was what already happened with a 'return' inside a try/catch block (exit only from current block). With this change, Avisynth+ is now inconsistent with Avisynth in this respect.
__________________
GScript and GRunT - complex Avisynth scripting made easier
Gavino is offline  
Old 9th December 2013, 01:30   #404  |  Link
ultim
AVS+ Dev
 
ultim's Avatar
 
Join Date: Aug 2013
Posts: 359
Quote:
Originally Posted by Gavino View Post
I can understand why you might consider the old behaviour to be a bug, but I made GScript work that way because that was what already happened with a 'return' inside a try/catch block (exit only from current block). With this change, Avisynth+ is now inconsistent with Avisynth in this respect.
We acknowlege this small inconsistency, but we believe that there almost no scripts affected, and so the advantages greatly outweight the downsides of this small deviation from AviSynth.
__________________
AviSynth+
ultim is offline  
Old 9th December 2013, 05:20   #405  |  Link
Mystery Keeper
Beyond Kawaii
 
Mystery Keeper's Avatar
 
Join Date: Feb 2008
Location: Russia
Posts: 724
Since you now let user customize plugins path, would you please add separate path for .avsi scripts?
__________________
...desu!
Mystery Keeper is offline  
Old 9th December 2013, 05:21   #406  |  Link
TurboPascal7
Registered User
 
TurboPascal7's Avatar
 
Join Date: Jan 2010
Posts: 270
Quote:
Originally Posted by Mystery Keeper View Post
Since you now let user customize plugins path, would you please add separate path for .avsi scripts?
What for?
__________________
Me on GitHub | AviSynth+ - the (dead) future of AviSynth
TurboPascal7 is offline  
Old 9th December 2013, 06:08   #407  |  Link
Mystery Keeper
Beyond Kawaii
 
Mystery Keeper's Avatar
 
Join Date: Feb 2008
Location: Russia
Posts: 724
To not copy them across 32 and 64 bit folders and keep them separated from the binaries.
__________________
...desu!
Mystery Keeper is offline  
Old 9th December 2013, 12:37   #408  |  Link
real.finder
Registered User
 
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
hi, what AutoloadPlugins() function do?

Did not mention here
real.finder is offline  
Old 9th December 2013, 13:31   #409  |  Link
ultim
AVS+ Dev
 
ultim's Avatar
 
Join Date: Aug 2013
Posts: 359
Quote:
Originally Posted by real.finder View Post
hi, what AutoloadPlugins() function do?

Did not mention here
It simply forces autoloading at the point it is called. Not usefull for scripts, it was meant to support editors like AvsPmod.
__________________
AviSynth+
ultim is offline  
Old 9th December 2013, 18:05   #410  |  Link
Groucho2004
 
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
I have been testing the 32 bit AVS+ version on XP64 with the following script to drive the memory usage above 2G:
Code:
setmemorymax(16384)
n = 9000
colorbars(width = n * 2, height = n, pixel_type = "yv12").killaudio().assumefps(24000, 1001)
trim(0,19)
pointresize(width() - 64, height() - 64).turnleft()
pointresize(width() + 64, height() + 64).turnright()
a=selectevery(3, 0).addborders(0,0, 16,0).crop(0,0, -16,0)
b=selectevery(3, 1).addborders(0,0, 32,0).crop(0,0, -32,0)
c=selectevery(3, 2).addborders(0,0, 64,0).crop(0,0, -64,0)
interleave(a, b, c)
Results with the "normal" Avisynth 2.6 Alpha5:
Code:
Frames processed:               20 (0 - 19)
FPS (min | max | average):      0.24 | 0.25 | 0.25
CPU usage (average):            25%
Thread count:                   2
Physical Memory usage (peak):   2330 MB
Virtual Memory usage (peak):    2324 MB
Time (elapsed):                 000:01:21.186
And with the latest AVS+ (x86):
Code:
Frames processed:               20 (0 - 19)
FPS (min | max | average):      0.53 | 0.61 | 0.60
CPU usage (average):            25%
Thread count:                   2
Physical Memory usage (peak):   3030 MB
Virtual Memory usage (peak):    3022 MB
Time (elapsed):                 000:00:33.140
AVS+ is obviously much faster but also uses a lot more memory. This might be an isolated case but I thought it might be worth reporting.
Groucho2004 is offline  
Old 9th December 2013, 19:51   #411  |  Link
ultim
AVS+ Dev
 
ultim's Avatar
 
Join Date: Aug 2013
Posts: 359
What eats memory are the resize functions. If you remove them, memory consumption sinks drastically.

Code:
setmemorymax(16384)
n = 9000
colorbars(width = n * 2, height = n, pixel_type = "yv12").killaudio().assumefps(24000, 1001)
trim(0,19)
turnleft()
turnright()
a=selectevery(3, 0).addborders(0,0, 16,0).crop(0,0, -16,0)
b=selectevery(3, 1).addborders(0,0, 32,0).crop(0,0, -32,0)
c=selectevery(3, 2).addborders(0,0, 64,0).crop(0,0, -64,0)
interleave(a, b, c)
Code:
Frames processed:               20 (0 - 19)
FPS (min | max | average):      1.38 | 1.65 | 1.59
CPU usage (average):            12%
Thread count:                   4
Physical Memory usage (peak):   1201 MB
Virtual Memory usage (peak):    1214 MB
Time (elapsed):                 000:00:12.605
__________________
AviSynth+
ultim is offline  
Old 9th December 2013, 21:39   #412  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,431
Quote:
Originally Posted by ultim View Post
We acknowlege this small inconsistency, but we believe that there almost no scripts affected, and so the advantages greatly outweight the downsides of this small deviation from AviSynth.
I agree the new semantics are more useful.
Perhaps IanB could be persuaded that the way Avisynth currently handles 'return' in try/catch is a bug, and should be fixed.

Looking at the changes to the Avisynth+ source code, I believe there is a flaw in the way 'return' has been implemented.
You have put the code to handle the new ReturnExprException into ScriptEnvironment::Invoke(). This will catch a 'return' from both script level and from a user function, but not from run-time scripts (eg in ScriptClip()), since the run-time filters call the parser directly and do not use Invoke(). I haven't actually tried it, but I think you will now get an unhandled exception if you use 'return' in a run-time script.

Conceptually, Invoke() also feels like the wrong place to handle this, as this exception is really just a parser thing and it would be cleaner to handle it fully inside the parser code.

My preferred solution would be to introduce a new Expression subclass 'ExpRoot' which the parser would use for the root of the expression tree (in ScriptParser::Parse()) and for function bodies (in ScriptParser::ParseFunctionDefinition). The ReturnExprException could then be caught in the Evaluate() of this new subclass.
__________________
GScript and GRunT - complex Avisynth scripting made easier
Gavino is offline  
Old 10th December 2013, 09:10   #413  |  Link
ultim
AVS+ Dev
 
ultim's Avatar
 
Join Date: Aug 2013
Posts: 359
Quote:
Originally Posted by Gavino View Post
I agree the new semantics are more useful.
Perhaps IanB could be persuaded that the way Avisynth currently handles 'return' in try/catch is a bug, and should be fixed.

Looking at the changes to the Avisynth+ source code, I believe there is a flaw in the way 'return' has been implemented.
You have put the code to handle the new ReturnExprException into ScriptEnvironment::Invoke(). This will catch a 'return' from both script level and from a user function, but not from run-time scripts (eg in ScriptClip()), since the run-time filters call the parser directly and do not use Invoke(). I haven't actually tried it, but I think you will now get an unhandled exception if you use 'return' in a run-time script.

Conceptually, Invoke() also feels like the wrong place to handle this, as this exception is really just a parser thing and it would be cleaner to handle it fully inside the parser code.

My preferred solution would be to introduce a new Expression subclass 'ExpRoot' which the parser would use for the root of the expression tree (in ScriptParser::Parse()) and for function bodies (in ScriptParser::ParseFunctionDefinition). The ReturnExprException could then be caught in the Evaluate() of this new subclass.
Correct. I will hotfix it tonight and edit this post when done. Thank you!
EDIT: The release is up. Contains a fix for the issue pointed out by Gavino, and also an installer fix as well as some visual update.
__________________
AviSynth+

Last edited by ultim; 11th December 2013 at 19:59.
ultim is offline  
Old 10th December 2013, 09:28   #414  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,308
Quote:
Originally Posted by ultim View Post
What eats memory are the resize functions.
Maybe in that case the question should be "Why...?".
Why the resize functions in avisynth+ use more memory ?
jpsdr is offline  
Old 10th December 2013, 09:37   #415  |  Link
TurboPascal7
Registered User
 
TurboPascal7's Avatar
 
Join Date: Jan 2010
Posts: 270
Quote:
Originally Posted by jpsdr View Post
Maybe in that case the question should be "Why...?".
Why the resize functions in avisynth+ use more memory ?
I described it here in part 9.
Now, current implementation is less memory efficient than it could be and this will get fixed some time soon. But we won't go back to the old way of doing it so avs+ resizers will always eat more memory than original.
__________________
Me on GitHub | AviSynth+ - the (dead) future of AviSynth
TurboPascal7 is offline  
Old 11th December 2013, 09:25   #416  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,308
Ok, thanks for the information.
jpsdr is offline  
Old 12th December 2013, 18:21   #417  |  Link
hector40
Registered User
 
Join Date: Oct 2010
Location: Sampa
Posts: 9
Hi, this script crash avspmod.

Code:
BlankClip(length=1000, width=720, height=480, pixel_type="yv12", fps=23.976)
a=last
crop(718, 0, -0, -0)
Repair(blur(1.0).AddBorders(718,0,0,0), last.AddBorders(718,0,0,0),1)
crop(718, 0, -0, -0)
overlay(a, last, mode="blend", opacity=1.0, x=718)
hector40 is offline  
Old 12th December 2013, 18:29   #418  |  Link
wOxxOm
Oz of the zOo
 
Join Date: May 2005
Posts: 208
Quote:
Originally Posted by hector40 View Post
Hi, this script crash avspmod.
yeah it does crash avs+ here too, so I simplified the script, the essential code is:
Code:
BlankClip(1000,720,480,"yv12")
overlay(last)
callstack:
Quote:
> avisynth.dll!convert_yv24_chroma_to_yv12_sse2(unsigned char * dstp, const unsigned char * srcp, int dst_pitch, int src_pitch, int dst_width, const int dst_height) Line 309 C++
avisynth.dll!Convert444ToYV12::ConvertImage(Image444 * src, PVideoFrame dst, IScriptEnvironment * env) Line 410 C++
avisynth.dll!Overlay::GetFrame(int n, IScriptEnvironment * env) Line 277 C++
avisynth.dll!Cache::childGetFrame(int n, IScriptEnvironment * env) Line 356 C++
avisynth.dll!Cache::GetFrame(int n, IScriptEnvironment * env) Line 557 C++
avisynth.dll!avs_get_frame(AVS_Clip * p, int n) Line 170 C++
On this line dst_width==360 for the chroma plane which is not mod16, so _mm_store_si128 crashes.
Should be an unaligned store which is also used in other functions:
Code:
_mm_storeu_si128(reinterpret_cast<__m128i*>(dstp+dst_width-16), avg);

Last edited by wOxxOm; 12th December 2013 at 20:28.
wOxxOm is offline  
Old 15th December 2013, 20:27   #419  |  Link
zerowalker
Registered User
 
Join Date: Jul 2011
Posts: 1,121
Is it possible to add Wave64 (or rather Wave over 4gb) support?

Itīs now possible to open it, but the time will incorrect, it will stop at some point before the actual end (Probably when it reaches the 4gb limit).

There is a workaround to use plugins, but most of the time Directshowsource does the work best.
zerowalker is offline  
Old 18th December 2013, 14:49   #420  |  Link
real.finder
Registered User
 
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
hi

About MT and setmtmode and the old closed Source filters

It would be better if setmtmode applied only on those filters

Because there are some filters will be slow with setmtmode, no matter mode were used

will be slower than without setmtmode, such as ffms2, especially with large files

So it would be good to apply setmtmode automatically with the proper mode on those filters only

And after one filter with setmtmode enabled, if there a filter with a different setmtmode mode will be changed automatically to that mode

in this case, avs+ will need a particular directory for those filters that will be used with setmtmode and the proper mode for each one of them

Otherwise, setmtmode will be cancel by the default

But the problem is the cancellation, setmtmode 5 and setmtmode 6 not good for this

Because I tried them with ffms2 and the speed was reduced, and of course I can use mp_pipeline to overcome such a problems, but it better to have a mechanism to stops setmtmode in the same script

----


For open source and the modern filters, they will use an internal MT

or running setmtmode with the proper mode into avs script, and cancel it if the next filter not need setmtmode

or it better to be a new and safe mt between the avs and the filters to be used in those cases away from setmtmode


thanks

Last edited by real.finder; 18th December 2013 at 15:18.
real.finder is offline  
Closed Thread

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 11:27.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.