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. |
3rd October 2013, 22:15 | #81 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
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. |
3rd October 2013, 23:10 | #82 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
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 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. |
3rd October 2013, 23:18 | #83 | Link |
AVS+ Dev
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. |
3rd October 2013, 23:56 | #84 | Link |
AVS+ Dev
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. |
4th October 2013, 00:25 | #85 | Link | |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
Quote:
|
|
4th October 2013, 00:51 | #86 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
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. |
4th October 2013, 07:49 | #87 | Link | |
AVS+ Dev
Join Date: Aug 2013
Posts: 359
|
Quote:
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. |
|
4th October 2013, 12:04 | #88 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
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"; } |
4th October 2013, 14:54 | #89 | Link | |
AVS+ Dev
Join Date: Aug 2013
Posts: 359
|
Quote:
Anyway, with that removed, my previously posted binary build of Avs+ should load your ffms2 correctly now. |
|
4th October 2013, 14:55 | #90 | Link | |
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
Quote:
With ultim's build, that's not necessary (and actually goes wrong) since LoadPlugin and LoadCPlugin are the same thing. |
|
4th October 2013, 15:38 | #91 | Link | |
AVS+ Dev
Join Date: Aug 2013
Posts: 359
|
Quote:
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. |
|
4th October 2013, 16:17 | #92 | Link | |
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
Quote:
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). |
|
4th October 2013, 16:48 | #93 | Link | |
AVS+ Dev
Join Date: Aug 2013
Posts: 359
|
Quote:
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. |
|
5th October 2013, 01:15 | #94 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
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. |
6th October 2013, 08:53 | #95 | Link |
Registered User
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. |
6th October 2013, 10:02 | #96 | Link |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,316
|
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... |
6th October 2013, 10:10 | #97 | Link |
Registered User
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.
|
6th October 2013, 11:22 | #98 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
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? |
6th October 2013, 13:03 | #100 | Link | ||
AVS+ Dev
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:
Quote:
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. |
||
|
|