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 18th December 2013, 15:15   #421  |  Link
wOxxOm
Oz of the zOo
 
Join Date: May 2005
Posts: 208
real.finder, instead of the outdated ffms2 can you please test L-SMASH Source's LSMASHVideoSource (for mp4/mov) and LWLibavVideoSource (for everything) in your avs mt workflow? If it isn't affected then maybe there is no problem to solve, just switch to L-S...
wOxxOm is offline  
Old 18th December 2013, 15:25   #422  |  Link
real.finder
Registered User
 
Join Date: Jan 2012
Location: Mesopotamia
Posts: 1,940
Quote:
Originally Posted by wOxxOm View Post
real.finder, instead of the outdated ffms2 can you please test L-SMASH Source's LSMASHVideoSource (for mp4/mov) and LWLibavVideoSource (for everything) in your avs mt workflow? If it isn't affected then maybe there is no problem to solve, just switch to L-S...
I mentioned ffms2 for example only

There may be other filters do not like setmtmode, and this known thing

in the past, I tested put setmtmode before mp_pipeline and make the process slower too
real.finder is offline  
Old 18th December 2013, 20:25   #423  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 1,846
I've quickly tested QTGMC v3.33 (just try to open file and view a few frames) under Windows XP64 SP2, with r1555.

Seems to works fine with VDub x86.

Not working with VDub x64, error message :
Code:
Cache Filter returned invalid response to CACHE_GETCHILD_CACHE_MODE. 78312696
.../plugins64/QTGMC.avsi line 784
.../plugins64/QTGMC.avsi line 387
.../Deinterlace_v2.avs line 2
Line 784 :
diff = mt_makediff( Ref, Input, U=3,V=3 )
Line 386 :
repair0 = (IsClip(srchClip) || Rep0 == 0) ? binomial0 : binomial0.QTGMC_KeepOnlyBobShimmerFixes( bobbed, Rep0, (RepChroma && ChromaMotion) )

My script :
Code:
AVISource("File.avi")
QTGMC(EdiMode="nnedi3",ChromaEdi="nnedi3",blocksize=8,overlap=4,search=5,searchparam=4,EdiThreads=6,ChromaMotion=false)
SelectEven()
Of course, this was working with avisynth64_4-16-10.
jpsdr is offline  
Old 18th December 2013, 20:33   #424  |  Link
real.finder
Registered User
 
Join Date: Jan 2012
Location: Mesopotamia
Posts: 1,940
you need mt_masktools-26.dll compile with new avs interface

Available in x86 by now, not for x64 until now, At least I didn't see one for 64 until now

Many filters need to have 64 ver.
real.finder is offline  
Old 18th December 2013, 21:43   #425  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 1,846
I have the x64 version of v2.0a48 for avs 2.6... Another new one is required ?
jpsdr is offline  
Old 18th December 2013, 21:50   #426  |  Link
TurboPascal7
Registered User
 
TurboPascal7's Avatar
 
Join Date: Jan 2010
Posts: 270
Quote:
Originally Posted by jpsdr View Post
I have the x64 version of v2.0a48 for avs 2.6... Another new one is required ?
Yes. I will publish a fork of masktools some time soon.
It doesn't mean that you'll be able to safely run QTGMC though since there are many more filters used.
__________________
Me on GitHub | AviSynth+ - the (dead) future of AviSynth
TurboPascal7 is offline  
Old 18th December 2013, 21:53   #427  |  Link
real.finder
Registered User
 
Join Date: Jan 2012
Location: Mesopotamia
Posts: 1,940
Quote:
Originally Posted by jpsdr View Post
I have the x64 version of v2.0a48 for avs 2.6... Another new one is required ?
avs 2.6 interface changed in alpha 4, So it need to recompiling with it, there is x86 by now only as I said

official mt_masktools-26.dll will not work with avs 2.6 alpha 4 and up

Of course avs+ also

you can use mt_masktools-25.dll but make sure there is no other mt_masktools in plugins autoload folder dir
real.finder is offline  
Old 18th December 2013, 22:03   #428  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 1,846
I've try to compile the project (VS2010) (source taken from v2.0a48)... Without succes. I've installed yasm according the description in the readme (vysasm.exe in "../VC/Bin" and props/target/xml in "../v4.0/BuildCustomizations").

When i try to generate project, i've the following error :
Code:
1>------ Début de la génération*: Projet*: common, Configuration*: release-avs26 Win32 ------
1>F:\PRG\Visual_2010\masktools-v2.0a48\common\build\yasm.targets(73,5): error MSB4023: Impossible d'évaluer la métadonnée d'élément "%(Extension)". Impossible d'appliquer la métadonnée d'élément "%(Extension)" au chemin d'accès ""Win32\release-avs26\\_functions.obj"". Caractères non conformes dans le chemin d'accès.
2>------ Début de la génération*: Projet*: masktools, Configuration*: release-avs26 Win32 ------
2>F:\PRG\Visual_2010\masktools-v2.0a48\masktools\build\yasm.targets(73,5): error MSB4023: Impossible d'évaluer la métadonnée d'élément "%(Extension)". Impossible d'appliquer la métadonnée d'élément "%(Extension)" au chemin d'accès ""Win32\release-avs26\\_functions.obj"". Caractères non conformes dans le chemin d'accès.
========== Génération*: 0 a réussi, 2 a échoué, 0 mis à jour, 0 a été ignoré ==========
Translation is something like :
Code:
1>------ Start generation*: Project*: common, Configuration*: release-avs26 Win32 ------
1>F:\PRG\Visual_2010\masktools-v2.0a48\common\build\yasm.targets(73,5): error MSB4023: Impossible to evaluate the metadata "%(Extension)". Impossible to apply the metadata "%(Extension)" to acces path ""Win32\release-avs26\\_functions.obj"". Characters not conform in the acces path.
2>------ Start generation*: Projet*: masktools, Configuration*: release-avs26 Win32 ------
2>F:\PRG\Visual_2010\masktools-v2.0a48\masktools\build\yasm.targets(73,5): error MSB4023: Impossible to evaluate the metadata "%(Extension)". Impossible to apply the metadata "%(Extension)" to acces path ""Win32\release-avs26\\_functions.obj"". Characters not conform in the acces path.
========== Génération*: 0 success, 2 failed, 0 updated, 0 ignored ==========

Last edited by jpsdr; 18th December 2013 at 22:08.
jpsdr is offline  
Old 18th December 2013, 22:09   #429  |  Link
Groucho2004
 
Join Date: Mar 2006
Location: Barcelona
Posts: 5,032
Quote:
Originally Posted by jpsdr View Post
I've try to compile the project (VS2010) (source taken from v2.0a48)... Without succes.
How is this related to AVS+?
Groucho2004 is offline  
Old 18th December 2013, 22:45   #430  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 1,846
Because... ... euh... after being able to compile the original source, i wanted to try to compile with the new avisynth.h from AVS+ ? ... not good...?
Ok sorry...
jpsdr is offline  
Old 18th December 2013, 22:56   #431  |  Link
TurboPascal7
Registered User
 
TurboPascal7's Avatar
 
Join Date: Jan 2010
Posts: 270
As I told you I will publish a fork of masktools some time soon. If you want to build it right now for whatever reason, feel free. But you'll need VS2012 for that.
__________________
Me on GitHub | AviSynth+ - the (dead) future of AviSynth
TurboPascal7 is offline  
Old 18th December 2013, 23:04   #432  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 1,846
Ok, thanks.
jpsdr is offline  
Old 19th December 2013, 09:40   #433  |  Link
ultim
AVS+ Dev
 
ultim's Avatar
 
Join Date: Aug 2013
Posts: 359
Quote:
Originally Posted by real.finder View Post
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
In AVS+, SetMTMode (with a different name) is implemented similarly to your idea, with minor differences. The way it works is instead of specifying the MT mode for all the filters that follow, AVS+'s setmtmode accepts the filter's name as its first parameter, and it then applies to all instances of that filter, and only to that filter. So basically it is what you have said, in that you can set the mt-mode for each filter once, and AVS+ will switch between mt modes automatically.

This has a couple of nice advantages:
  • First, obviously, your scripts don't need to be modified in their middle. There is no need to insert dozens of setmtmode calls all over a script, and you can keep the actual script logic and setmtmode calls separate cleanly.
  • Second, this approach allows you to move the setmtmode calls for all of your installed plugins into one script that contains nothing but all the setmtmode calls, which you can then include in your other scripts. Meaning you'll only need to maintain one set of setmtmode calls.
  • Even better than my previous point, you don't even need to include the setmtmode specifications in all of your scripts, you can just let it autoload like any other .avsi script. In AVS+, setmtmode is not what enables parallel processing, so you can safely call setmtmode in any script even if you don't want to run it multithreaded. Multithreading is enabled by a different call that you can add to only those scripts that use MT-capable plugins. (setmtmode merely specifies how to multithread a filter if MT is enabled at all)

Miscellaneous notes:
  • In AVS+, "SetMTMode" is actually called "SetFilter(MT)Mode". This is partially to differentiate scripts written for AVS+ from scripts written for AVS-MT, and also to more clearly indicate that this call does not set the MT mode globally, but only for a particular filter.
  • However, the same call can also be used to set the default MT mode for all filters that have no other MT mode set.
  • Plugins can also indicate to AVS+ which MT mode they need over their API. If this is specified by a plugin, it will normally take precedence over the mode set by the script, because it is more likely to be correct (a user's manual setting can easily be out-of-date, or just simply incorrect). If a plugin specifies the MT mode for itself, there is no need to specify it in scripts at all.
  • SetFilterMTMode also has a second, boolean "force" parameter, optional and defaulting to false. If this is set to true in a script, that mode will take precedence over any other calls for the same filter where "force" was false. It will then also take precedence over the mode specified by the plugin internally.

The priority scheme of setfiltermode calls may sound complex, but it is really simple. To summarize:
  1. If a filter has a forced mode set, it will use that.
  2. Otherwise, it will use a non-forced mode, if it has any.
  3. If it does not have any mode set, it will use the default mode for all filters.
  4. Mode setting does not have any effect until MT is actually enabled (so it is still safe to set even the default mode in any script).

---------------------------

What I have described above is already done and implemented, except for filters being able to indicate their MT mode on their own to AVS+. However, due to some other reasons related mostly to caching, the MT-version of AVS+ isn't ripe enough yet, which is why it isn't included in the public builds currently.
__________________
AviSynth+

Last edited by ultim; 19th December 2013 at 10:54.
ultim is offline  
Old 19th December 2013, 09:54   #434  |  Link
ultim
AVS+ Dev
 
ultim's Avatar
 
Join Date: Aug 2013
Posts: 359
Quote:
Originally Posted by jpsdr View Post
Cache Filter returned invalid response to CACHE_GETCHILD_CACHE_MODE.
For future reference, if anybody sees the message above, it means the plugin is not compatible with AviSynth 2.6a4. For clarification, Avs+ uses the 2.6a4 interface.

What you can do at this point, is look in the forums if anybody has published an updated build of the same plugin, or recompile the plugin yourself.

Recompiling a 2.5 plugin for 2.6a4 will need some modifications to the plugin's source, but only very simple things. If you're a developer, it will definitely be easy (given that the pre-2.6a4 version can be recompiled, which for some plugins will be much harder than the actual porting to 2.6a4).
__________________
AviSynth+

Last edited by ultim; 19th December 2013 at 10:54.
ultim is offline  
Old 19th December 2013, 13:17   #435  |  Link
ryrynz
Registered User
 
ryrynz's Avatar
 
Join Date: Mar 2009
Posts: 3,378
Looking forward to seeing MT in action, will it follow the same logic and performance as SEt's MTmodes?
If there is possibly no need to specify modes in scripts at all if the filter overrides it, will you provide a message stating this on runtime so it can be removed by the user? I'd rather not have unecessary lines in the script.
I was hoping to see a MT build soon, probably next month now?
ryrynz is offline  
Old 19th December 2013, 13:29   #436  |  Link
real.finder
Registered User
 
Join Date: Jan 2012
Location: Mesopotamia
Posts: 1,940
The only thing that makes me use SEt's build in my encoding by now and don't use avs+ is mt

So I also wait avs+ MT build
real.finder is offline  
Old 19th December 2013, 19:09   #437  |  Link
ultim
AVS+ Dev
 
ultim's Avatar
 
Join Date: Aug 2013
Posts: 359
Quote:
Originally Posted by ryrynz View Post
Looking forward to seeing MT in action, will it follow the same logic and performance as SEt's MTmodes?
Not sure what you mean by "same logic". It will have the same MT modes 1-3 as SEt's version.

Quote:
Originally Posted by ryrynz View Post
If there is possibly no need to specify modes in scripts at all if the filter overrides it, will you provide a message stating this on runtime so it can be removed by the user? I'd rather not have unecessary lines in the script.
Maybe, in the future, but not right at the start. Those "unnecessary" lines should not disturb you as they will not have any effect, and if you autoload the setfiltermode lines they won't pollute your scripts.

Quote:
Originally Posted by ryrynz View Post
I was hoping to see a MT build soon, probably next month now?
I was planning originally to release in november, but RL stepped in to prevent that. So no guarantees, but I do hope I'll get more opportunities to work on it in the holiday season. Rest assured, MT is coming, and more features will after that.
__________________
AviSynth+
ultim is offline  
Old 19th December 2013, 20:59   #438  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 1,846
I have somehow just a little question.
I'm trying to port to x64 nnedi3 v0.9.4. My first step is to put on external asm files all the _asm inside. I've just begun (here), it's going slowly, but i'm progressing. When done and tested, my second step will be to convert the asm file to x64. But, for now, during the first step, i'm begining to think of the second step, and i've noticed something different from what i'm used to in VDub (i've made personnaly several filters for VDub, but asm was always in asm files, never inline, so updating to x64 was less less difficult).
In VDub, all pointer related data (offset/pitch) are in ptrdiff_t, which allow an excellent portability x86/x64, specialy when you write asm functions, and pass pitch parameters which are used directly to compute on address data.
I've noticed, in the code of nnedi3, and after taking a look at avisynth.h, that in avisynth these parameters are int. Int is 32 bits even on x64... In the process of updatind and making avisynth more portable for x64, don't you think it could be interesting to think about having offset/pitch pointer parameters of avisynth picture data in ptrdiff_t ? It's the same thing as int on x86 (32 bits signed), but they will be 64 bits signed on x64, more logical for pointer offset data.
Well, it's just my little thought.

Last edited by jpsdr; 19th December 2013 at 21:42.
jpsdr is offline  
Old 19th December 2013, 22:10   #439  |  Link
ultim
AVS+ Dev
 
ultim's Avatar
 
Join Date: Aug 2013
Posts: 359
You are not the first to suggest that some data types should be changed, but we cannot do so without breaking existing x64 filters.

Either way, offset/pitch being only ints isn't really a problem. Offset merely stores the displacement of a frame's plane from it's base pointer, so this is not a problem since your planes will be lot less smaller than 2GBs. Similarly, pitch is the displacement from the beginning from one line to the next, and since a single row of samples will rarely hit 2GBs in size, this doesn't pose any realistic limitation. So offset/pitch aren't pointers, both are offsets from pointers within a single frame, hence I don't see how this is a portability issue. It won't even cause a problem with pointer arithmetic in C. You might need to take special precautions in ASM to get correct results out of pointer math, but I'm not the expert in that area.
__________________
AviSynth+
ultim is offline  
Old 19th December 2013, 23:18   #440  |  Link
TurboPascal7
Registered User
 
TurboPascal7's Avatar
 
Join Date: Jan 2010
Posts: 270
If you plan on going external asm, please consider using x264 abstraction thingy over simply changing the code to be x64-only. It's always better to have a single source that can compile to both x64 and x86 instead of two different codebases. You can find example usage in x264 or vapoursynth.
__________________
Me on GitHub | AviSynth+ - the (dead) future of AviSynth
TurboPascal7 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 01:42.


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