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

Reply
 
Thread Tools Search this Thread Display Modes
Old 7th February 2014, 12:27   #581  |  Link
naoan
Registered User
 
Join Date: Oct 2009
Posts: 152
Quote:
Originally Posted by ultim View Post
If it needs to be last, you can also place it after the call to Prefetch().
Nice! didn't know you could do it like that, seems a bit faster/less frame drop now. Thanks!
naoan is offline   Reply With Quote
Old 7th February 2014, 13:42   #582  |  Link
kypec
User of free A/V tools
 
kypec's Avatar
 
Join Date: Jul 2006
Location: SK
Posts: 830
I've replaced my Avisynth installation with your x86 build and also replaced AvsPmod files but now AvsPmod refuses to even start with error message below:

Clicking "Yes" and navigating to C:\Windows\SysWOW64 where that Avisynth+ DLL resides does not work either.
kypec is offline   Reply With Quote
Old 7th February 2014, 20:39   #583  |  Link
ryrynz
Registered User
 
ryrynz's Avatar
 
Join Date: Mar 2009
Posts: 3,203
Hoping for a build that works with ffdshow, tried it on both my computers win8/win7 i7/i5 and both crash instantly, both are working fine with 2.6MT.
ryrynz is offline   Reply With Quote
Old 8th February 2014, 10:15   #584  |  Link
turbojet
Registered User
 
Join Date: May 2008
Posts: 1,840
blankclip(1630,1920,1080,"YV12",23.976)
Code:
resize(1280,1080) AVS+  2.6
Lanczos           139   153
Spline64          142   135
Bicubic           241   175
Bilinear          246   240
Same conclusion as Groucho2004's test with lanczos included.
__________________
PC: FX-8320 GTS250 HTPC: G1610 GTX650
PotPlayer/MPC-BE LAVFilters MadVR-Bicubic75AR/Lanczos4AR/Lanczos4AR LumaSharpen -Strength0.9-Pattern3-Clamp0.1-OffsetBias2.0
turbojet is offline   Reply With Quote
Old 8th February 2014, 21:16   #585  |  Link
ultim
AVS+ Dev
 
ultim's Avatar
 
Join Date: Aug 2013
Posts: 359
So here are some more news I've promised. The list of our Google Summer of Code ideas is online! It is available from the homepage with a single click, but here is a direct link for you. You'll find all kinds of interesting projects there, from native GPU support to scripting language improvements and a GUI plugin manager, just to name a few. Now, cross your fingers for AviSynth to be accepted.
__________________
AviSynth+
ultim is offline   Reply With Quote
Old 8th February 2014, 21:21   #586  |  Link
Stereodude
Registered User
 
Join Date: Dec 2002
Location: Region 0
Posts: 1,132
Your direct link gives a 404.

I also have a question about AviSynth+. I see a big push related to MT in the past week. I thought the whole idea was to get better performance without requiring the user to mess around with MT commands and the like? I'm probably put off to the idea because my experience with MT support in AviSynth is that it's a complete disaster that barely works even on the rare occasions when the stars align just right and I'd not rather not have those headaches again. I've had much better luck with MP_Pipeline at speeding up scripts than I ever had with MT and it doesn't require any sort of celestial alignment or blood sacrifices.

Last edited by Stereodude; 8th February 2014 at 21:34.
Stereodude is offline   Reply With Quote
Old 8th February 2014, 21:37   #587  |  Link
ultim
AVS+ Dev
 
ultim's Avatar
 
Join Date: Aug 2013
Posts: 359
Quote:
Originally Posted by Stereodude View Post
Your direct link gives a 404.
Works for me.


Quote:
Originally Posted by Stereodude View Post
I also have a question about AviSynth+. I see a big push related to MT in the past week. I thought the whole idea was to get better performance without requiring the user to mess around with MT commands and the like?
Ultimately, that is what everybody (including us developers) would like to see. But unfortunately what you wish for is simply technically not possible for many filters due to the way they work. What we can do though is to minimize the MT-related commands the user has to issue, instead of completely eliminating them. Minimizing the MT-commands for script writers is the collective goal of many of our efforts, such as many filter rewrites (both internal and external), adding support for filters to signal to Avs+ the MT mode they need, the way SetFilterMTMode() works, and even of this post to teach plugin developers how to support MT hassle-free for the user.

So we do what we can, but sometimes there are hard limits to what is possible at all.
__________________
AviSynth+
ultim is offline   Reply With Quote
Old 8th February 2014, 21:57   #588  |  Link
TurboPascal7
Registered User
 
TurboPascal7's Avatar
 
Join Date: Jan 2010
Posts: 270
Quote:
Originally Posted by Stereodude View Post
I thought the whole idea was to get better performance without requiring the user to mess around with MT commands and the like?
That's right. When MT is finalized, the only thing the user will have to write in his script is the Prefetch call, which later can probably be added by programs like avsmeter, avs2yuv and the likes. All SetFilterMtMode calls will be hidden in a single .avsi script.

Compared to all those ### MT_Pipeline requires you to write, this is nothing.

Now, the problem is to build this avsi file with MT modes definitions. I put this pad about two weeks ago and posted the link on our IRC channel, ultim also linked it here a few days ago. But since the initial script, only one line has been added (fft3dgpu). With this kind of activity you can't expect MT to get finalized and become user-side overhead free any time soon.
__________________
Me on GitHub | AviSynth+ - the (dead) future of AviSynth
TurboPascal7 is offline   Reply With Quote
Old 10th February 2014, 18:31   #589  |  Link
HeadlessCow
Registered User
 
Join Date: Nov 2002
Posts: 131
Quote:
Originally Posted by TurboPascal7 View Post
That's right. When MT is finalized, the only thing the user will have to write in his script is the Prefetch call, which later can probably be added by programs like avsmeter, avs2yuv and the likes. All SetFilterMtMode calls will be hidden in a single .avsi script.

Compared to all those ### MT_Pipeline requires you to write, this is nothing.

Now, the problem is to build this avsi file with MT modes definitions. I put this pad about two weeks ago and posted the link on our IRC channel, ultim also linked it here a few days ago. But since the initial script, only one line has been added (fft3dgpu). With this kind of activity you can't expect MT to get finalized and become user-side overhead free any time soon.
Is there a reason why you couldn't require the filters to implement a new method that returns the MT modes that they support rather than relying on a community generated avsi script? You'd still need the script for older plugins, but anything new (or anything that you're updating) would just automatically work.
HeadlessCow is offline   Reply With Quote
Old 10th February 2014, 20:28   #590  |  Link
TurboPascal7
Registered User
 
TurboPascal7's Avatar
 
Join Date: Jan 2010
Posts: 270
Quote:
Originally Posted by HeadlessCow View Post
Is there a reason why you couldn't require the filters to implement a new method that returns the MT modes that they support rather than relying on a community generated avsi script? You'd still need the script for older plugins, but anything new (or anything that you're updating) would just automatically work.
No, there is no reason we couldn't do this. That's why we did. It works by abusing SetCacheHints right now but allows keeping backward compatibility.
__________________
Me on GitHub | AviSynth+ - the (dead) future of AviSynth
TurboPascal7 is offline   Reply With Quote
Old 10th February 2014, 21:56   #591  |  Link
HeadlessCow
Registered User
 
Join Date: Nov 2002
Posts: 131
Quote:
Originally Posted by TurboPascal7 View Post
No, there is no reason we couldn't do this. That's why we did. It works by abusing SetCacheHints right now but allows keeping backward compatibility.
Ah, perfect (and sneaky)! I hadn't seen mention of it in the thread, so I just wanted to make sure the obvious option hadn't been accidentally overlooked :-D
HeadlessCow is offline   Reply With Quote
Old 11th February 2014, 07:13   #592  |  Link
turbojet
Registered User
 
Join Date: May 2008
Posts: 1,840
Here's some results with fastest mt mode:

tfm 1
tdecimate 3 or off, 1 fails
telecide 1
decimate 3 or off, 1 and 2 fails
fielddeinterlace 2, 1 fails
dss2 1, 2 is very slow
lwlibavvideosource(dr=true) 2 is 25% faster with much higher cpu usage, 75 vs 17%, 1 fails
nnedi3 2, 1 corruption
colormatrix("Rec.709->Rec.601") 2 is <1% faster than all modes or off
dfttest 1
fdecimate 1 and 2 tie
it 3, 1 fails, 2 is same speed as 3 but 4x cpu load
jinc36resize(3840,2160) 2, 1 is corrupt
leakkerneldeint(1) 1
repal 3, 1 fails, 2 is slow
sorathread 3, 1 and 2 fails
srestore all tie
tdeint 1
unblend 1 or 2
uncomb 3 or off
unsharphq 1
yadif 1
yadifmod(edeint=nnedi3()) 2, 1 fails

All defaults unless (). When testing it's best to use a real source, some filters work on blankclip() but not on real sources
with the same mtmode.

Mode 1 works on quite a few things. One thing I didn't consider (much) is cpu load. I used prefetch(4) which 50% with most filters while mode 3 and off used 12%. mtmodes during realtime watching should be a big benefit but unless slow filters are used there's a little bit of a slowdown when x264 encoding.
__________________
PC: FX-8320 GTS250 HTPC: G1610 GTX650
PotPlayer/MPC-BE LAVFilters MadVR-Bicubic75AR/Lanczos4AR/Lanczos4AR LumaSharpen -Strength0.9-Pattern3-Clamp0.1-OffsetBias2.0

Last edited by turbojet; 11th February 2014 at 08:16.
turbojet is offline   Reply With Quote
Old 11th February 2014, 07:21   #593  |  Link
TurboPascal7
Registered User
 
TurboPascal7's Avatar
 
Join Date: Jan 2010
Posts: 270
Please do check if the actual output is correct. Fast but broken mode is useless.
I'm asking because for example nnedi3 with mode 1 is completely broken yet you specified it. I'm pretty sure that's the case with most filters in the list.
Easy way of checking would be using something like ColorBars(1920, 1080, "YV12").addgrainc(10000, 10000, seed=1) as a source filter. It doesn't always work right but will do for most stuff (like needi3).
__________________
Me on GitHub | AviSynth+ - the (dead) future of AviSynth

Last edited by TurboPascal7; 11th February 2014 at 07:33.
TurboPascal7 is offline   Reply With Quote
Old 11th February 2014, 07:59   #594  |  Link
turbojet
Registered User
 
Join Date: May 2008
Posts: 1,840
Does the corruption like nnedi3 only happen with mode 1?
__________________
PC: FX-8320 GTS250 HTPC: G1610 GTX650
PotPlayer/MPC-BE LAVFilters MadVR-Bicubic75AR/Lanczos4AR/Lanczos4AR LumaSharpen -Strength0.9-Pattern3-Clamp0.1-OffsetBias2.0
turbojet is offline   Reply With Quote
Old 11th February 2014, 08:06   #595  |  Link
TurboPascal7
Registered User
 
TurboPascal7's Avatar
 
Join Date: Jan 2010
Posts: 270
Quote:
Originally Posted by turbojet View Post
Does the corruption like nnedi3 only happen with mode 1?
It most cases - yes.

Nnedi3 uses some buffers to do its dirty work and with mode 1 you get multiple threads writing data from different frames to the same buffer. This causes corruption when later someone tries to read from this buffer and gets not what was expected. Most of "more complicated" filters use some kind of temporary storage thus won't work well with this mode. Simple filters might.

Mode 2 doesn't have this issue because multiple threads will get their own buffers and no data will be shared. Hence mode 2 is the "default" mode which should work with most filters, but it wastes memory like crazy (take SangNom2 for example - for 1080p YV12 frame, size of temporary buffers is about 10MB, so with 4 threads you get 40MBs on single filter invocation. Now add some usual supersampling to this and multiple invocations in most aa scripts and... you get the idea).

If the filter requires sequential access or uses some global storage (i.e. written by a very bad person), then mode 3 is the only way to go.
__________________
Me on GitHub | AviSynth+ - the (dead) future of AviSynth

Last edited by TurboPascal7; 11th February 2014 at 08:22.
TurboPascal7 is offline   Reply With Quote
Old 11th February 2014, 08:17   #596  |  Link
turbojet
Registered User
 
Join Date: May 2008
Posts: 1,840
Tested all the reported 1's and other than nnedi3, jinc36resize didn't look correct. Others worked fine.
__________________
PC: FX-8320 GTS250 HTPC: G1610 GTX650
PotPlayer/MPC-BE LAVFilters MadVR-Bicubic75AR/Lanczos4AR/Lanczos4AR LumaSharpen -Strength0.9-Pattern3-Clamp0.1-OffsetBias2.0
turbojet is offline   Reply With Quote
Old 11th February 2014, 18:53   #597  |  Link
ultim
AVS+ Dev
 
ultim's Avatar
 
Join Date: Aug 2013
Posts: 359
Quote:
Originally Posted by HeadlessCow View Post
Ah, perfect (and sneaky)! I hadn't seen mention of it in the thread, so I just wanted to make sure the obvious option hadn't been accidentally overlooked :-D
It wasn't mentioned to avoid plugin writers accidentially using those parts of the new interface which are not safe. The MT-mode specification is safe, but be sure not to use IScriptEnvironment2 at all, for exmaple.

The good thing about MT-mode specification as shown by TurboPascal7, as he already noted, is that it keeps compatibility. So plugins can implemnent it without breaking older AviSynth versions, or non-plus AviSynth. Putting it into SetCacheHints() is ugly I know (TurboPascal7 was very much against it putting it there for this reason), but it is the only way for me to let plugins report their MT-mode without breaking other AviSynths.

Anyway, long story short, you can follow the example here, but don't use any other part of the new interface yet. For plugins that report the MT mode using SetCacheHint(), the user won't have to add a SetFilterMode() call.
__________________
AviSynth+
ultim is offline   Reply With Quote
Old 11th February 2014, 21:12   #598  |  Link
LaTo
LaTo INV.
 
LaTo's Avatar
 
Join Date: Jun 2007
Location: France
Posts: 701
What is a good way to detect Avisynth+ without losing compatibility with regular Avisynth?
I need that to automatically disable internal multi-threading in my filters.
Thanks.

Last edited by Guest; 11th February 2014 at 21:39. Reason: 12
LaTo is offline   Reply With Quote
Old 11th February 2014, 21:47   #599  |  Link
Groucho2004
►◄
 
Groucho2004's Avatar
 
Join Date: Mar 2006
Location: A wretched hive of scum and villainy
Posts: 4,398
Quote:
Originally Posted by LaTo View Post
What is the best way to detect Avisynth+ without losing compatibility with regular Avisynth?
I need that to automatically disable internal multi-threading in my filters.
Thanks.
There are several ways to identify the avisynth.dll.

1. Query "AVISYNTH_INTERFACE_VERSION". This only tells you if it's 2.5x or 2.6x

2. Parse the version string ("VersionString"). A bit unreliable.

3. Parse the export functions. That's the most useful and what I do in AVSMeter. For example:
Only 2.6x versions export "DeleteScriptEnvironment()"
Only AVS+ exports "CreateScriptEnvironment2"
Only SEt's and tsp's MT versions export "GetMTMode()".

A combination of the above should provide enough info.
Groucho2004 is offline   Reply With Quote
Old 12th February 2014, 08:30   #600  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 1,751
Quote:
Originally Posted by LaTo View Post
What is a good way to detect Avisynth+ without losing compatibility with regular Avisynth?
I need that to automatically disable internal multi-threading in my filters.
Thanks.
Should it be better to detect if MT mode is enabled ?
If someone use Avisynth+ without using multi-threading, i think internal multi-threading should be kept.
jpsdr is offline   Reply With Quote
Reply

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 07:55.


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