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.

 Doom9's Forum Avisynth+
 Register FAQ Calendar Search Today's Posts Mark Forums Read

 4th December 2013, 00:05 #381  |  Link turbojet Registered User   Join Date: May 2008 Posts: 1,840 So lanczos is faster but one or more of spline36, spline64, sinc, bicubic, sinc is slower? __________________ PC: FX-8320 GTS250 HTPC: G1610 GTX650 PotPlayer/MPC-BE LAVFilters MadVR-Bicubic75AR/Lanczos4AR/Lanczos4AR LumaSharpen -Strength0.9-Pattern3-Clamp0.1-OffsetBias2.0
4th December 2013, 00:15   #382  |  Link
TurboPascal7
Registered User

Join Date: Jan 2010
Posts: 270
Quote:
 Originally Posted by turbojet So lanczos is faster but one or more of spline36, spline64, sinc, bicubic, sinc is slower?
It depends on the core size (different resizers), source and destination resolutions, your CPU model and the moon phase. I get 15% better performance on Groucho2004's script btw.
__________________
Me on GitHub | AviSynth+ - the (dead) future of AviSynth

 4th December 2013, 03:01 #383  |  Link innocenat Registered User     Join Date: Dec 2011 Posts: 77 I will explain problem with resizer slowdown in detail: 1. Larger memory footprint: Due to the new resizers are implemented as ResizeVertical.TurnRight.ResizeVertical.TurnLeft, this unfortunately requires two buffers to hold intermediate transposed frame. These buffers are quite large (frame size) and are the cause of increased memory footprint. But IMO, this is not really significant. If it bothers you, I can try to reduce memory footprint a bit, but it isn't possible to match original memory footprint with this implementation. 2. Performance varies between each resizers: Because without Softwire (a just-in-time assembler), the innermost loop of resizers cannot be unrolled to exact filter size. This loop runs a lot (~35 million times on Spline36Resize upscale from 720p to 1080p) and is very optimized. Loop overhead becomes noticeable here, and is reason why filters with large core size run more slower. Generally, Point > Bilinear > Bicubic = Spline16 > Spline36 = Lanczos3 > Spline64 = Lanczos. 3. Performance drop compared to original Avisynth: This is where things get really weird. All resizers run faster than original on Nehalem CPUs, but it look like they run slower on almost every other CPUs (including Intel's newer CPUs like Sandy Bridge). On older CPUs, it may caused by branch predictor cannot predict the innermost loop perfectly (the cycles require to run innermost loop is smaller than branch predictor penalties on most CPUs), but tests has confirmed that this is not a case for newer CPUs. There are some extra instruction generated by compiler in pre-innermost loop, which unfortunately is intrinsics limitation compared to pure asm. tl;dr situation is weird and no one currently know what is actually happening.
4th December 2013, 03:32   #384  |  Link
Groucho2004
►◄

Join Date: Mar 2006
Location: A wretched hive of scum and villainy
Posts: 4,459
Quote:
 Originally Posted by innocenat I will explain problem with resizer slowdown in detail: 1. Larger memory footprint: Due to the new resizers are implemented as ResizeVertical.TurnRight.ResizeVertical.TurnLeft, this unfortunately requires two buffers to hold intermediate transposed frame. These buffers are quite large (frame size) and are the cause of increased memory footprint. But IMO, this is not really significant. If it bothers you, I can try to reduce memory footprint a bit, but it isn't possible to match original memory footprint with this implementation. 2. Performance varies between each resizers: Because without Softwire (a just-in-time assembler), the innermost loop of resizers cannot be unrolled to exact filter size. This loop runs a lot (~35 million times on Spline36Resize upscale from 720p to 1080p) and is very optimized. Loop overhead becomes noticeable here, and is reason why filters with large core size run more slower. Generally, Point > Bilinear > Bicubic = Spline16 > Spline36 = Lanczos3 > Spline64 = Lanczos. 3. Performance drop compared to original Avisynth: This is where things get really weird. All resizers run faster than original on Nehalem CPUs, but it look like they run slower on almost every other CPUs (including Intel's newer CPUs like Sandy Bridge). On older CPUs, it may caused by branch predictor cannot predict the innermost loop perfectly (the cycles require to run innermost loop is smaller than branch predictor penalties on most CPUs), but tests has confirmed that this is not a case for newer CPUs. There are some extra instruction generated by compiler in pre-innermost loop, which unfortunately is intrinsics limitation compared to pure asm. tl;dr situation is weird and no one currently know what is actually happening.
Actually, with "normal" scripts like simply scaling from 720p to 1080p or vice versa, the speed and memory usage differences are marginal. In some cases, AVS+ is even faster.

So, this is a rather insignificant issue. It's much more important that things work and people don't have to restart their process after 20 hours because Avisynth MT crashed for some reason.

 4th December 2013, 08:21 #385  |  Link qyot27 ...?     Join Date: Nov 2005 Location: Florida Posts: 1,081 Not that I'm asking about its relevance to the resizer situation*, but if SoftWire was a JIT assembler, does that mean AviSynth used it for roughly the same reason that Schrödinger uses the Oil Runtime Compiler? The description for ORC seems rather similar to what it looks like SoftWire did. *namely because it's stupid slow to build on anything not recent EDIT: haha, apparently it got brought up a couple years ago in here. Last edited by qyot27; 4th December 2013 at 08:39.
 4th December 2013, 09:24 #386  |  Link ultim AVS+ Dev     Join Date: Aug 2013 Posts: 359 A part of the increased memory consumption is also the result of the plugin manager. That is however just as planned, and the difference will depend on the amount of plugins (meaning it is constant, and will not increase with encoding time or script size/complexity). As for some filters being best optimized currently for Nehalem, I might add the reason is because (as far as I've gathered but I'm not totally sure) all the plugin devs have Nehalem CPUs, so that is where they can test the most. As for dynamic compilers, my personal opinion is that today it is best (most future proof) to go with LLVM. There is a related idea for Avs+ for GSoC, but not for the resizers. I wouldn't make the core dependent on *any* compiler library though, such functionality if anyone works on it will come as a separate plugin.
 4th December 2013, 22:45 #387  |  Link jpsdr Registered User   Join Date: Oct 2002 Location: France Posts: 1,758 I've just installed/tested the actual release under Windows XP64 SP2. The few tests i've made seems ok. One thing to report about the installer, it doesn't create a menu. Is it normal ? Otherwise, thanks for your work at all the guys who are in this project. Finaly, a properly x64 version is on the way.
4th December 2013, 23:19   #388  |  Link
ultim
AVS+ Dev

Join Date: Aug 2013
Posts: 359
Quote:
 Originally Posted by jpsdr I've just installed/tested the actual release under Windows XP64 SP2. The few tests i've made seems ok. One thing to report about the installer, it doesn't create a menu. Is it normal ? Otherwise, thanks for your work at all the guys who are in this project. Finaly, a properly x64 version is on the way.
Thanks, in the name of everybody who worked / is working on the project.

About the Start Menu entries, yes they are not created by the current installer. Start Menu entries will come in a future release.

Last edited by ultim; 4th December 2013 at 23:27.

 6th December 2013, 04:33 #389  |  Link zerowalker Registered User   Join Date: Jul 2011 Posts: 1,101 Does Avisynth+ have problems with using VirtualDub plugins? I am getting errors here and there, though not sure if it´s Avisynth+ or not, haven´t tried using others yet. Here are the errors, they come and go and it well, can be used in some way but it can also crash the decoder for the script (Avspmod often just produces errors, Virtualdub will crash if i give it the script 2 times in a row, and i think it fails to decode properly anyway). Exception WindowsError: 'exception: access violation reading 0x0C412C00' in > ignored An out-of-bounds memory access (access violation) occurred in module 'VirtualDub'... ...reading address 069D2C00. LoadVirtualDubPlugin("E:\Virtualdub\32 bit - Stable\plugins\addframenumber.vdf", "addframenumber",1) That is the plugin i am using: http://www.neuron2.net/guest/ Well may be something totally else, and if so it´s off topic EDIT: Okay i got rid of it after testing all kinds of stuff, it had something to do with MixAudio being used after the VirtualPlugin, so probably just som incompatibility, but i just changed the order and now it seems to work, made no sense having it after the Plugin anyway. So i guess it was just a False Alarm from my side. Last edited by zerowalker; 6th December 2013 at 04:48.
 7th December 2013, 11:15 #390  |  Link jpsdr Registered User   Join Date: Oct 2002 Location: France Posts: 1,758 I've installed a few days ago avisynth+ on Windows XP64 SP2 to test (and use) the x64 version. The only functions i've used in my scripts for now are AviSource, WavSource, AudioDub, Spline36Resize, PointResize (which was not working on last avisynth64 release) and DGSource. I've run several process of several hours with VDub64, no issue encounter. I've run encodes of several hours with x264 (x64 version, of course, .avs file feed directly, but only AviSource used in that case), no issue encounter. I've not tested a lot of avisynth functions, but at least, it seems to work properly with applications, and doesn't seem to have, at least for the few i've tested, any stability issue. Good work, guys !
 8th December 2013, 07:59 #391  |  Link aegisofrime Registered User   Join Date: Apr 2009 Posts: 462 Hi Guys, I just tried Avisynth+ for the first time on my encoding rig, and I have been having some strange problems getting it to work. I have the following script: Code: LoadPlugin("C:\DGIndex\DGDecode.dll") DGDecode_mpeg2source("I:\Test\Test.d2v", info=3) LoadPlugin("C:\Program Files (x86)\MeGUI\tools\avisynth_plugin\ColorMatrix.dll") ColorMatrix(hints=true, threads=0) QTGMC(Preset="Slower") crop(4, 0, -4, 0) #resize Spline64Resize(720,480) #denoise Pretty simple QTGMC script. Now, the problem is that the script can be opened by some applications but not by others: MeGUI: Stuck at opening script (preview window doesn't open), just keeps loading and loading. No errors thrown. x264 input: Just says cannot open Test.avs Virtualdub: Works Lord Mulder's Simple x264 Launcher: Provides the most information of the bunch, says: Code: error: Cannot load file 'C:/DGIndex/DGDecode.dll' Unless the loadplugin syntax was changed in Avisynth+, I have no idea what's wrong here. Hope some of you can provide some wisdom here... Thanks!
 8th December 2013, 08:23 #392  |  Link vivan /人 ◕ ‿‿ ◕ 人\   Join Date: May 2011 Location: Russia Posts: 649 Probably it's this issue: http://forum.doom9.org/showthread.ph...69#post1655169
 8th December 2013, 10:14 #393  |  Link real.finder Registered User   Join Date: Jan 2012 Location: Mesopotamia Posts: 1,286 Hi I have a suggestion Function to change the path of autoload folder temporarily in the script something like:- PluginsDir("new plugins path will be here") and for + Plugins PluginsPlusDir("new plugins+ path will be here") in the top of script, like:- Code: PluginsDir("D:\plugins") PluginsPlusDir("D:\plugins+") MPEG2Source("C:\Documents and Settings\user\Desktop\video.d2v") Tfm() Would be a wonderful thing for users who without authority of admin -------- On the other hand, I'm still waiting for MT support in order to use avs+ mainly in my encoding thanks
8th December 2013, 10:34   #394  |  Link
innocenat
Registered User

Join Date: Dec 2011
Posts: 77
Quote:
 Originally Posted by real.finder PluginsDir("new plugins path will be here") and for + Plugins PluginsPlusDir("new plugins+ path will be here")

You don't need separate folder --- the command only works in Avs+ which can load either anyway,

8th December 2013, 10:45   #395  |  Link
real.finder
Registered User

Join Date: Jan 2012
Location: Mesopotamia
Posts: 1,286
Quote:
 Originally Posted by innocenat try AddAutoloadDir("C:\path\to\dir") You don't need separate folder --- the command only works in Avs+ which can load either anyway,

find it here

thank you

8th December 2013, 12:31   #396  |  Link
aegisofrime
Registered User

Join Date: Apr 2009
Posts: 462
Quote:
 Originally Posted by vivan Probably it's this issue: http://forum.doom9.org/showthread.ph...69#post1655169
Thanks for the reply, however it doesn't seem to be the case since the script works in Virtualdub, and anyway my LoadPlugin is before the DGDecode call...

 8th December 2013, 12:52 #397  |  Link StainlessS HeartlessS Usurer     Join Date: Dec 2009 Location: Over the rainbow Posts: 7,197 @aegisofrime, does Info() at end of script show anything of interest in VD ? NOTE, VD has it's own decoders/colorspace converters. EDIT: Empty plugins directory temporarily (except for any necessary plugs). EDIT: Although problem seems directory related for DGDecode. EDIT: You could verify DGIndex load as cause using below Code: RT_Debug("Loading DGIndex") LoadPlugin("C:\DGIndex\DGDecode.dll") RT_Debug("DGIndex Loaded") And view output in DebugView (google) (RT_Debug requires RT_Stats plug). __________________ I sometimes post sober. StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace "Some infinities are bigger than other infinities", but how many of them are infinitely bigger ??? Last edited by StainlessS; 8th December 2013 at 13:47.
8th December 2013, 15:43   #398  |  Link
aegisofrime
Registered User

Join Date: Apr 2009
Posts: 462
Quote:
 Originally Posted by StainlessS @aegisofrime, does Info() at end of script show anything of interest in VD ? NOTE, VD has it's own decoders/colorspace converters. EDIT: Empty plugins directory temporarily (except for any necessary plugs). EDIT: Although problem seems directory related for DGDecode. EDIT: You could verify DGIndex load as cause using below Code: RT_Debug("Loading DGIndex") LoadPlugin("C:\DGIndex\DGDecode.dll") RT_Debug("DGIndex Loaded") And view output in DebugView (google) (RT_Debug requires RT_Stats plug).
I took your advice of cleaning out my plugins folder, and moved back the important ones for QTGMC. It works now, so it seems there was an offending filter in my admittedly messy plugins folder. The strange thing is that the same plugin collection works on my Windows 8 laptop without a hitch.

If I have time I will track down and see what's the filter that's causing this issue.

 8th December 2013, 16:00 #399  |  Link StainlessS HeartlessS Usurer     Join Date: Dec 2009 Location: Over the rainbow Posts: 7,197 I had some problems some time ago with Avisynth ffmpegSource() and Vdub Plugins32 FFImputDriver.vdplugin and the ffdlls directory in VDub plugin32, the presence of ffdlls in vd plugs dir caused some kind of conflict with avisynth, cant remember exactly what the problem was, but seemed related to ffmpegSource and/or FFImputDriver versions. Might want to check out by restoring original plugins but without the suspect plugins in AVS/VD plugs dir. I think the problem was something to do with directory search order being changed, it may have nothing to do with the problem, but would be first thing I would try out. __________________ I sometimes post sober. StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace "Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???
8th December 2013, 19:01   #400  |  Link
qyot27
...?

Join Date: Nov 2005
Location: Florida
Posts: 1,081
Quote:
 Originally Posted by StainlessS I had some problems some time ago with Avisynth ffmpegSource() and Vdub Plugins32 FFImputDriver.vdplugin and the ffdlls directory in VDub plugin32, the presence of ffdlls in vd plugs dir caused some kind of conflict with avisynth, cant remember exactly what the problem was, but seemed related to ffmpegSource and/or FFImputDriver versions. Might want to check out by restoring original plugins but without the suspect plugins in AVS/VD plugs dir. I think the problem was something to do with directory search order being changed, it may have nothing to do with the problem, but would be first thing I would try out.
That would have to do with the really really early builds of FFmpegSource 1.x that relied on shared versions of the FFmpeg libraries. The builds switched to including those statically somewhere in the middle of the 1.x dev cycle (back in like, 2008 or something) and it's never been done as shared for Windows builds of FFMS2.

 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 Rules
 Forum Jump User Control Panel Private Messages Subscriptions Who's Online Search Forums Forums Home Announcements and Chat     General Discussion     News     Forum / Site Suggestions & Help General     Decrypting     Newbies     DVD2AVI / DGIndex     Audio encoding     Subtitles     Linux, Mac OS X, & Co Capturing and Editing Video     Avisynth Usage     Avisynth Development     VapourSynth     Capturing Video     DV     HDTV / DVB / TiVo     NLE - Non Linear Editing     VirtualDub, VDubMod & AviDemux     New and alternative a/v containers Video Encoding     (Auto) Gordian Knot     MPEG-4 ASP     MPEG-4 Encoder GUIs     MPEG-4 AVC / H.264     High Efficiency Video Coding (HEVC)     New and alternative video codecs     MPEG-2 Encoding (HD) DVD, Blu-ray & (S)VCD     One click suites for DVD backup and DVD creation     DVD & BD Rebuilder     (HD) DVD & Blu-ray authoring     Advanced authoring     IFO/VOB Editors     DVD burning Hardware & Software     Software players     Hardware players     PC Hard & Software Programming and Hacking     Development     Translations

All times are GMT +1. The time now is 22:48.

 Doom9.org - Archive - Top