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. |
8th December 2013, 23:57 | #401 | Link |
AVS+ Dev
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:
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+ |
9th December 2013, 00:36 | #402 | Link |
AVS+ Dev
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. |
9th December 2013, 01:07 | #403 | Link |
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
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.
|
9th December 2013, 01:30 | #404 | Link | |
AVS+ Dev
Join Date: Aug 2013
Posts: 359
|
Quote:
__________________
AviSynth+ |
|
9th December 2013, 18:05 | #410 | Link |
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) 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 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 |
9th December 2013, 19:51 | #411 | Link |
AVS+ Dev
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+ |
9th December 2013, 21:39 | #412 | Link | |
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
Quote:
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. |
|
10th December 2013, 09:10 | #413 | Link | |
AVS+ Dev
Join Date: Aug 2013
Posts: 359
|
Quote:
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. |
|
10th December 2013, 09:37 | #415 | Link | |
Registered User
Join Date: Jan 2010
Posts: 270
|
Quote:
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. |
|
12th December 2013, 18:21 | #417 | Link |
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) |
12th December 2013, 18:29 | #418 | Link | |
Oz of the zOo
Join Date: May 2005
Posts: 208
|
yeah it does crash avs+ here too, so I simplified the script, the essential code is:
Code:
BlankClip(1000,720,480,"yv12") overlay(last) Quote:
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. |
|
15th December 2013, 20:27 | #419 | Link |
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. |
18th December 2013, 14:49 | #420 | Link |
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. |
Thread Tools | Search this Thread |
Display Modes | |
|
|