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 3rd October 2013, 22:15   #81  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,419
I don't think it's a missing dependency, because builds of the previous HEAD (BitBlt refactor) can load it, and looking at that build and the current HEAD in Dependency Walker show that the only three missing ones - EFSADU.DLL, IESHIMS.DLL, and WER.DLL - are missing from both of them. Did rewriting the plugin management bring in a new dependency?

I'm going to try running a Debug build and see if it catches anything.
qyot27 is offline  
Old 3rd October 2013, 23:10   #82  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,419
I really can't figure out the MSVC debugger, but both DebugView and gdb picked up on the following when I tried to run a script with a Debug build of AviSynth+ in ffmpeg:
Code:
warning: DllMain: hModule=0x10000000, ulReason=1, lpReserved=0x00000000, gRefCnt = 0

warning: StringDump: Allocating new stringblock.

[avisynth @ 03792c00] Script error: There is no function named 'ffindex'.
(C:/Program Files/AviSynth 2.5/plugins/FFMS2.avsi, line 31)
(test.avs, line 1)
warning: StringDump: DeAllocating all stringblocks.

test.avs: Unknown error occurred
warning: DllMain: hModule=0x10000000, ulReason=0, lpReserved=0x00000000, gRefCnt = 0
Dunno if that helps.



I did try to bisect it, though, and the issue arises with the rewritten plugin management in 9567b94e. The commit immediately before it works. I'm going to see if it's okay on some of the other computers I have access to.
qyot27 is offline  
Old 3rd October 2013, 23:18   #83  |  Link
ultim
AVS+ Dev
 
ultim's Avatar
 
Join Date: Aug 2013
Posts: 359
Thx for your efforts. I'm debugging it right now too. I've narrowed down the problem onto the 2.5 interface not working with ffms2, but dunno yet why. Don't try it on other machines, it won't work either.

The reason it worked for me, is because to make sure that ffms2 will be loaded with the C interface (and not 2.5), I've changed the interface probation order on my computer. Loading ffms2's does really work then, and I'm 100% sure it does on your computer too.

The problem is, that the binary I've published searches for the Avs 2.5 interface before the C interface, and because ffms2 also has that, Avs+ will use that instead of the C interface. This is where things start to get interesting. The call is made to the AvisynthPluginInit2 function, but it never registers any functions. I see it in your sources that it should correctly call Env->AddFunction, yet during runtime those calls never get back to me. I still have to find out why.

Last edited by ultim; 3rd October 2013 at 23:23.
ultim is offline  
Old 3rd October 2013, 23:56   #84  |  Link
ultim
AVS+ Dev
 
ultim's Avatar
 
Join Date: Aug 2013
Posts: 359
The problem seems to be in your build of ffms2. If I use TheRyuu's binary of 2.19 (the post right after yours in http://forum.doom9.org/showthread.php?p=1643738#post1643738), then it works perfectly. If I then overwrite ffms2.dll with your build r836, it stops working again.

Whatever the differences are in the source or compilation steps between your and TheRyuu's binary, it breaks your Avisynth 2.5 interface in ffms2.
ultim is offline  
Old 4th October 2013, 00:25   #85  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,419
Quote:
Originally Posted by ultim View Post
The problem seems to be in your build of ffms2. If I use TheRyuu's binary of 2.19 (the post right after yours in http://forum.doom9.org/showthread.php?p=1643738#post1643738), then it works perfectly. If I then overwrite ffms2.dll with your build r836, it stops working again.

Whatever the differences are in the source or compilation steps between your and TheRyuu's binary, it breaks your Avisynth 2.5 interface in ffms2.
The difference between them is that TheRyuu's build is the regular C++ plugin from the master branch, not the C plugin. The C plugin sources are in the src/avisynth_c directory (which only exists in the c_plugin branch), and completely ignores the src/avisynth directory since that's the C++ interface.
qyot27 is offline  
Old 4th October 2013, 00:51   #86  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,419
And after experimenting with the checking order in avs_core/core/PluginManager.cpp, swapping the C and 2.5 checks, FFMS2 does indeed work. But then AssRender stops loading.

EDIT: Totally disregard the AssRender thing, I'd forgotten I'd moved it out of the plugins folder.

Last edited by qyot27; 4th October 2013 at 00:57.
qyot27 is offline  
Old 4th October 2013, 07:49   #87  |  Link
ultim
AVS+ Dev
 
ultim's Avatar
 
Join Date: Aug 2013
Posts: 359
Quote:
Originally Posted by qyot27 View Post
The difference between them is that TheRyuu's build is the regular C++ plugin from the master branch, not the C plugin. The C plugin sources are in the src/avisynth_c directory (which only exists in the c_plugin branch), and completely ignores the src/avisynth directory since that's the C++ interface.
Even if you say that the Cplugin-build completely ignores the other directory, an entry point for AvisynthPluginInit2 is still generated in the Cplugin, which makes Avs(+) think that it supports the C++ interface. I'd suggest removing that method (or at least not exporting it) in the C plugin build if it is officially not working anyway, to prevent Avisynth servers from trying to load that interface. Then everything will work.

Whether you remove the C++ entry point from the C build or not, I'm changing the loading order in my next public build. Meaning that the new order will be 2.6 -> C -> 2.5. Not just because of ffms2, I've already written in #74 (that was before you've mentioned your problem with ffms2) that this change should happen. ffms2 is just yet another reason. But I still think you should remove AvisynthPluginInit2 from the C-build if it is not intended to work anyway.
ultim is offline  
Old 4th October 2013, 12:04   #88  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,419
It's true that the C plugin doesn't build anything from the src/avisynth directory, in that the GNUmakefile never refers to it. The reference to AvisynthPluginInit2 is in src/avisynth_c/avisynth.c, though, which is where all of this ends up getting caught.

The offending code block in question:
Code:
/* the AVS loader for LoadPlugin.
* Allows the conditional avs script logic:
* ( LoadPlugin("ffms2.dll") == "Use LoadCPlugin" ) ? LoadCPlugin("ffms2.dll") : NOP()
* to successfully load the plugin for both MSVC and MinGW versions */
const char * __stdcall AvisynthPluginInit2( void *Env )
{ return "Use LoadCPlugin"; }
So it would appear it was put in there for some sort of LoadPlugin trickery, but I can't see any reason for it either. I've removed it locally so that the C-plugin only uses the C interface init.
qyot27 is offline  
Old 4th October 2013, 14:54   #89  |  Link
ultim
AVS+ Dev
 
ultim's Avatar
 
Join Date: Aug 2013
Posts: 359
Quote:
Originally Posted by qyot27 View Post
Code:
/* the AVS loader for LoadPlugin.
* Allows the conditional avs script logic:
* ( LoadPlugin("ffms2.dll") == "Use LoadCPlugin" ) ? LoadCPlugin("ffms2.dll") : NOP()
* to successfully load the plugin for both MSVC and MinGW versions */
const char * __stdcall AvisynthPluginInit2( void *Env )
{ return "Use LoadCPlugin"; }
Because Avisynth has been supporting both Cplugins and C++ plugins for a long time now, that piece of code doesn't look too meaningful for me either. Both MSVC and MinGW versions of ffms2 should be able to load using LoadCPlugin, so instead of writing that condition into a script, the script author could simply just use LoadCPlugin. I think that hack must be really old.

Anyway, with that removed, my previously posted binary build of Avs+ should load your ffms2 correctly now.
ultim is offline  
Old 4th October 2013, 14:55   #90  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,431
Quote:
Originally Posted by qyot27 View Post
Code:
/* the AVS loader for LoadPlugin.
* Allows the conditional avs script logic:
* ( LoadPlugin("ffms2.dll") == "Use LoadCPlugin" ) ? LoadCPlugin("ffms2.dll") : NOP()
* to successfully load the plugin for both MSVC and MinGW versions */
const char * __stdcall AvisynthPluginInit2( void *Env )
{ return "Use LoadCPlugin"; }
So it would appear it was put in there for some sort of LoadPlugin trickery, but I can't see any reason for it either.
It makes sense in vanilla Avisynth, as you can use the highlighted line in a script to load ffms2.dll regardless of whether you have the C++ or C version.

With ultim's build, that's not necessary (and actually goes wrong) since LoadPlugin and LoadCPlugin are the same thing.
__________________
GScript and GRunT - complex Avisynth scripting made easier
Gavino is offline  
Old 4th October 2013, 15:38   #91  |  Link
ultim
AVS+ Dev
 
ultim's Avatar
 
Join Date: Aug 2013
Posts: 359
Quote:
Originally Posted by Gavino View Post
It makes sense in vanilla Avisynth, as you can use the highlighted line in a script to load ffms2.dll regardless of whether you have the C++ or C version.

With ultim's build, that's not necessary (and actually goes wrong) since LoadPlugin and LoadCPlugin are the same thing.

AFAIK, vanilla Avisynth also has C-plugin support, so it doesn't seem to make sense to me, because instead of writing "( LoadPlugin("ffms2.dll") == "Use LoadCPlugin" ) ? LoadCPlugin("ffms2.dll") : NOP()" the script author could say "LoadCPlugin("ffms2.dll")" in both projects.

But more importantly, with these changes the plugin should now be able to load in both vanilla Avisynth and in Avisynth+.

Last edited by ultim; 4th October 2013 at 15:55.
ultim is offline  
Old 4th October 2013, 16:17   #92  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,431
Quote:
Originally Posted by ultim View Post
AFAIK, vanilla Avisynth also has C-plugin support, so it doesn't seem to make sense to me, because instead of writing "( LoadPlugin("ffms2.dll") == "Use LoadCPlugin" ) ? LoadCPlugin("ffms2.dll") : NOP()" the script author could say "LoadCPlugin("ffms2.dll")" in both projects.
But that won't work if the ffms2.dll you have is the C++ version. The point of using the conditional line in the script is that the user doesn't need to know which version he actually has if he loads it that way.

However, he could also use a try/catch instead and that would not require the extra code in the C plugin. The same script would then work in both Avisynth and Avisynth+. (In avs+, the try/catch would be unnecessary, but harmless).
__________________
GScript and GRunT - complex Avisynth scripting made easier
Gavino is offline  
Old 4th October 2013, 16:48   #93  |  Link
ultim
AVS+ Dev
 
ultim's Avatar
 
Join Date: Aug 2013
Posts: 359
Quote:
Originally Posted by Gavino View Post
But that won't work if the ffms2.dll you have is the C++ version. The point of using the conditional line in the script is that the user doesn't need to know which version he actually has if he loads it that way.
Ah, now I finally get it. I was assuming all the way through that the user would be using the Cplugin version of ffms2. Thx for making it clear to me.

As I said before, I'm gonna change Avisynth+ to try the C interface of a plugin before the 2.5 interface anyway. That will solve these problems too, and the user would be able to use both the C and C++ version of ffms2 with any of the two Avisynth projects, even if qyot27 decides not to remove those lines. I guess it is even better then if leaves those lines there, for the users who are using that hack.
ultim is offline  
Old 5th October 2013, 01:15   #94  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,419
I actually did remove them, because the real need for that hack is only if ffms2.dll is not in the autoloading folder. The C-plugin (well, my builds of it) has long had LoadCPlugin("ffms2.dll") included in FFMS2.avsi, which handles it for classic AviSynth, and the C++ version would autoload on classic anyway. The inclusion of LoadCPlugin in FFMS2.avsi got merged into the main c_plugin branch after FFMS2 officially moved to git about a month ago.

I've not issued a pull request for it yet, so it's only in my personal FFMS2 repo.
qyot27 is offline  
Old 6th October 2013, 08:53   #95  |  Link
TurboPascal7
Registered User
 
TurboPascal7's Avatar
 
Join Date: Jan 2010
Posts: 270
Great job, ultim, I'm really happy to see someone not ancient working on avisynth.
What I would like to see is some kind of a roadmap. In a form of github issues or just a page in the wiki, but anything that would help developers start contributing would be really helpful. I assume x64 and multithreading support is planned in the (not near) future?

And two more questions:
1. What is the reason to keep compatibility with 2005 runtime when you can target XP with 2008/10/11 just fine (11 might be having some problems in wine though)?
2. What exactly breaks AvsPmod compatibility? This problem is really important since it renders the project useless for a lot of people.
TurboPascal7 is offline  
Old 6th October 2013, 10:02   #96  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,309
I also be happy to see an x64 version, but from what i've understood, two big steps are needed.
1 - Remove all the inline asm and put it on external asm files.
2 - Rewrite these asm file to be x64 compliant.
The work already done in the already existant x64 version may help, nevertheless, it still seems to be a very big work...
jpsdr is offline  
Old 6th October 2013, 10:10   #97  |  Link
TurboPascal7
Registered User
 
TurboPascal7's Avatar
 
Join Date: Jan 2010
Posts: 270
I wouldn't mind helping rewriting the asm to intrinsics but I don't think I can handle external asm files for long (nor do I think it's reasonable but that's another question). That's the main reason I asked about vs2005 support - I'm not sure how good it is with intrinsics and using external asm might be the only option.
TurboPascal7 is offline  
Old 6th October 2013, 11:22   #98  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,419
I'd mentioned it in a PM, but AvxSynth (which can build and work on x64 just fine) did have asm disabled and replaced with regular C/C++ versions that could get re-used, although for all I know it may have just merged that stuff in from Avisynth64. From what I understand there was a push a couple years ago or so to convert the asm in AviSynth to x264ASM, which would result in separating the stuff out anyway. Not to mention cross-platform interests and the possibility of non-x86 CPU architectures.


On a different tangent, I'd prefer if there was a more project-specific setup on Github. It's a lot easier to remember, say, github.com/avisynthplus/avisynthplus.git than having it as simply a personal repo of avisynth as it currently is. For that matter, shouldn't the thread title also be changed now too?
qyot27 is offline  
Old 6th October 2013, 12:03   #99  |  Link
vdcrim
Registered User
 
Join Date: Dec 2011
Posts: 192
Quote:
Originally Posted by TurboPascal7 View Post
2. What exactly breaks AvsPmod compatibility?
Just fixed in current git.

The $InternalFunctions$ and $PluginFunctions$ global vars are gone since the plugin management rewrite. Was that by mistake?
vdcrim is offline  
Old 6th October 2013, 13:03   #100  |  Link
ultim
AVS+ Dev
 
ultim's Avatar
 
Join Date: Aug 2013
Posts: 359
I will add issues to the Wiki to start with, and most probably I should also add a main README.md to the GitHub project so that visitors there get some more information other than the dump of a repository.

Right now I'm still looking at exception usage in Avisynth, continuously doing smaller cleanups and refactorings. I've also started to add Gavino's scripting extensions to Avisynth+, but I had to ask him because GScript and Avisynth have slightly different licensing terms. Fortunately he is completely okay with the integration (I've just received reply), so I can continue with that. I've also spent some time since the last release inspecting alternatives to the current BitBlt, so let us hope that it will result in a slight performance improvement. If there will be any, it won't be large, but at least it will be uniform (not specific to certain plugins or scripts).

Adding good threading is on the top of my wish-list too, and I am trying to find ways. As of right now there are parts of the Avisynth code involved which I did not investigate fully yet (mostly related to caching), so first I need to figure that part out completely.

x64 support is also a goal, but certianly not for the near-future. As many of you have said, the greatest obstacle here are the pieces of inline asm. I must admit that I'm not very versed in x86 asm, so here too I will be counting on your help.

Quote:
Originally Posted by TurboPascal7 View Post
1. What is the reason to keep compatibility with 2005 runtime when you can target XP with 2008/10/11 just fine (11 might be having some problems in wine though)?
It is more like, there is no reason to drop its support yet. Right now the most I could use from later VS versions is support for the C++11 STL (shared/unique_ptr, atomic, threading), but these are only available in VS2012, so that would be too limiting. This is also the reason I'm considering adding Boost as a dependency, to not have to rely on VS2012 yet still be able to make use of these libraries.

Quote:
Originally Posted by TurboPascal7 View Post
2. What exactly breaks AvsPmod compatibility? This problem is really important since it renders the project useless for a lot of people.
To be able to specify autoload directories in scripts, I had to delay autoloading plugins to the latest point possible. (As a comparison, upstream Avisynth autoloads plugins as soon as the ScriptingEnvironment is initialized, way before any script is loaded.) The result is that, in Avisynth+, the list of plugin functions is not available until a script has been loaded, so for now I have removed exporting special variables like $PluginFunctions$, $Plugin!...!Param$ and $InternalFunctions$, because they didn't make too much sense with the modifications in place. I suspect AvsPmod tries to read these, which is where the conflict comes from.

The best way to solve this would be to (both needed)
- Make AvsPmod only read these variables once a script has been loaded (so that autoload directories that were specified in the script can be taken into account)
- and add the ability to Avisynth+ to force autoloading from the standard directories (to faciliate writing new scripts). This is easy to accomplish without extending the binary interface.

The above two points require modifications to both Avisynth+ and AvsPmod.

Last edited by ultim; 6th October 2013 at 13:11.
ultim 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 22:49.


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