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 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
turbojet is offline  
Old 4th December 2013, 00:15   #382  |  Link
TurboPascal7
Registered User
 
TurboPascal7's Avatar
 
Join Date: Jan 2010
Posts: 270
Quote:
Originally Posted by turbojet View Post
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
TurboPascal7 is offline  
Old 4th December 2013, 03:01   #383  |  Link
innocenat
Registered User
 
innocenat's Avatar
 
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.
innocenat is offline  
Old 4th December 2013, 03:32   #384  |  Link
Groucho2004
 
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
Quote:
Originally Posted by innocenat View Post
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.
Groucho2004 is offline  
Old 4th December 2013, 08:21   #385  |  Link
qyot27
...?
 
qyot27's Avatar
 
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.
qyot27 is offline  
Old 4th December 2013, 09:24   #386  |  Link
ultim
AVS+ Dev
 
ultim's Avatar
 
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.
ultim is offline  
Old 4th December 2013, 22:45   #387  |  Link
jpsdr
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.
jpsdr is offline  
Old 4th December 2013, 23:19   #388  |  Link
ultim
AVS+ Dev
 
ultim's Avatar
 
Join Date: Aug 2013
Posts: 359
Quote:
Originally Posted by jpsdr View Post
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.
ultim is offline  
Old 6th December 2013, 04:33   #389  |  Link
zerowalker
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.
zerowalker is offline  
Old 7th December 2013, 11:15   #390  |  Link
jpsdr
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 !
jpsdr is offline  
Old 8th December 2013, 07:59   #391  |  Link
aegisofrime
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
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!
aegisofrime is offline  
Old 8th December 2013, 08:23   #392  |  Link
vivan
/人 ◕ ‿‿ ◕ 人\
 
Join Date: May 2011
Location: Russia
Posts: 643
Probably it's this issue: http://forum.doom9.org/showthread.ph...69#post1655169
vivan is offline  
Old 8th December 2013, 10:14   #393  |  Link
real.finder
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()
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
real.finder is offline  
Old 8th December 2013, 10:34   #394  |  Link
innocenat
Registered User
 
innocenat's Avatar
 
Join Date: Dec 2011
Posts: 77
Quote:
Originally Posted by real.finder View Post

PluginsDir("new plugins path will be here")

and for + Plugins

PluginsPlusDir("new plugins+ path will be here")
try AddAutoloadDir("C:\path\to\dir")

You don't need separate folder --- the command only works in Avs+ which can load either anyway,
innocenat is offline  
Old 8th December 2013, 10:45   #395  |  Link
real.finder
Registered User
 
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
Quote:
Originally Posted by innocenat View Post
try AddAutoloadDir("C:\path\to\dir")

You don't need separate folder --- the command only works in Avs+ which can load either anyway,
aha, so it's already exist

find it here

thank you
real.finder is offline  
Old 8th December 2013, 12:31   #396  |  Link
aegisofrime
Registered User
 
Join Date: Apr 2009
Posts: 478
Quote:
Originally Posted by vivan View Post
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...
aegisofrime is offline  
Old 8th December 2013, 12:52   #397  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
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")
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.
StainlessS is offline  
Old 8th December 2013, 15:43   #398  |  Link
aegisofrime
Registered User
 
Join Date: Apr 2009
Posts: 478
Quote:
Originally Posted by StainlessS View Post
@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.
aegisofrime is offline  
Old 8th December 2013, 16:00   #399  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
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 ???
StainlessS is offline  
Old 8th December 2013, 19:01   #400  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,419
Quote:
Originally Posted by StainlessS View Post
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.
qyot27 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 15:22.


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