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. |
4th December 2013, 00:05 | #381 | Link |
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, 03:01 | #383 | Link |
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 | |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
Quote:
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 |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,419
|
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 |
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 |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,309
|
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 | |
AVS+ Dev
Join Date: Aug 2013
Posts: 359
|
Quote:
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 |
Registered User
Join Date: Jul 2011
Posts: 1,121
|
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 <bound method PIScriptEnvironment.__del__ of <avisynth.PIScriptEnvironment instance at 0x034DD828>> 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 |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,309
|
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 |
Registered User
Join Date: Apr 2009
Posts: 478
|
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 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' Hope some of you can provide some wisdom here... Thanks! |
8th December 2013, 08:23 | #392 | Link |
/人 ◕ ‿‿ ◕ 人\
Join Date: May 2011
Location: Russia
Posts: 643
|
Probably it's this issue: http://forum.doom9.org/showthread.ph...69#post1655169
|
8th December 2013, 10:14 | #393 | Link |
Registered User
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
|
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() -------- On the other hand, I'm still waiting for MT support in order to use avs+ mainly in my encoding thanks |
8th December 2013, 12:31 | #396 | Link | |
Registered User
Join Date: Apr 2009
Posts: 478
|
Quote:
|
|
8th December 2013, 12:52 | #397 | Link |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
@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")
__________________
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 | |
Registered User
Join Date: Apr 2009
Posts: 478
|
Quote:
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 |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
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 | |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,419
|
Quote:
|
|
Thread Tools | Search this Thread |
Display Modes | |
|
|