Indent to get Avisynth working with Wine/Winelib
Hi, I am the developer of the C interface for Avisynth. Avisynth is a very popular Open Source tool for for video post-production for Win32. More information can be found at http://www.avisynth.org/. My intent is to get Avisynth working under Linux with the help of Wine/Winelib. Since it normal interface is VC++ recompiling it under Winelib is not really an option as that will mean that existing plugins for Avisynth will no longer work without a recompile. My main purpose of the C API I am developing is to act as a bridge so that GCC compiled programs can communicate with it. This will allow it to be used as a filter in Linux programs, and should even allow Linux specific plugins to work with Avisynth under Linux. But first I need to get Avisynth working under wine. I filed a bug report on the matter, http://bugs.winehq.org/show_bug.cgi?id=1707 , and would really appreciate if someone could look into it. After I get Avisynth working I need to be able to call the DLL from Linux. I believe that is possible but I can't seam to find out how after looking over the winelib docks. After that I might want to avoid having to use the full blown wine emulator by only proving the API calls Avisynth really needs much like the method used to get windows codec working under Linux. But first I need to get Avisynth working under wine. I know very little about Windows development or wine so I really can't fix the bug on my own. Thanks in advance. -- http://kevin.atkinson.dhs.org
On Wed, 10 Sep 2003, Kevin Atkinson wrote:
My intent is to get Avisynth working under Linux with the help of Wine/Winelib. Since it normal interface is VC++ recompiling it under Winelib is not really an option as that will mean that existing plugins for Avisynth will no longer work without a recompile. My main purpose of the C API I am developing is to act as a bridge so that GCC compiled programs can communicate with it. This will allow it to be used as a filter in Linux programs, and should even allow Linux specific plugins to work with Avisynth under Linux.
Good. Did you have a Makefile that will build this under MinGW. If yes, all you have to do is use winegcc & wrc instead of gcc and windres (however, winegcc is still in development, and can't generate DLLs, but that's another story). If no, please port it first to MinGW.
But first I need to get Avisynth working under wine. I filed a bug report on the matter, http://bugs.winehq.org/show_bug.cgi?id=1707 , and would really appreciate if someone could look into it.
OK, I accepted the bug, I'll help you out.
After I get Avisynth working I need to be able to call the DLL from Linux. I believe that is possible but I can't seam to find out how after looking over the winelib docks.
This is not currently possible, sorry. How big is this interface to avisynth? The only option ATM is to have it out-of-process, so we'll need to come up with some sort of stub/proxy, if you're interested. -- Dimi.
On Wed, 10 Sep 2003, Dimitrie O. Paun wrote:
On Wed, 10 Sep 2003, Kevin Atkinson wrote:
My intent is to get Avisynth working under Linux with the help of Wine/Winelib. Since it normal interface is VC++ recompiling it under Winelib is not really an option as that will mean that existing plugins for Avisynth will no longer work without a recompile. My main purpose of the C API I am developing is to act as a bridge so that GCC compiled programs can communicate with it. This will allow it to be used as a filter in Linux programs, and should even allow Linux specific plugins to work with Avisynth under Linux.
Good. Did you have a Makefile that will build this
What is this? Avisynth needs VC++. My API needs VC++ as it acts as the bridge and must make VC++ calls to avisynth. Everything can be gcc. And in fact I have successfully cross compiled Avisynth filters using my new C interface. The test case included a Makefile for compiling it.
But first I need to get Avisynth working under wine. I filed a bug report on the matter, http://bugs.winehq.org/show_bug.cgi?id=1707 , and would really appreciate if someone could look into it.
OK, I accepted the bug, I'll help you out.
Thanks.
After I get Avisynth working I need to be able to call the DLL from Linux. I believe that is possible but I can't seam to find out how after looking over the winelib docks.
This is not currently possible, sorry. How big is this interface to avisynth? The only option ATM is to have it out-of-process, so we'll need to come up with some sort of stub/proxy, if you're interested.
Hu? As I said I am pretty Win32 ignorant. -- http://kevin.atkinson.dhs.org
On Wed, 10 Sep 2003, Kevin Atkinson wrote:
This is not currently possible, sorry. How big is this interface to avisynth? The only option ATM is to have it out-of-process, so we'll need to come up with some sort of stub/proxy, if you're interested.
Hu? As I said I am pretty Win32 ignorant.
This has nothing to do with Win32. You simply can not link a Winelib DLL into a Linux app due to a lot of things too tricky to explain here. So there are two possible solutions: -- transform the apps that want to use avisynth into Winelib apps -- run avisynth in a separate process, and devise some sort of RPC mechanism to marshall calls back and forth. -- Dimi.
On Wed, 10 Sep 2003, Dimitrie O. Paun wrote:
On Wed, 10 Sep 2003, Kevin Atkinson wrote:
This is not currently possible, sorry. How big is this interface to avisynth? The only option ATM is to have it out-of-process, so we'll need to come up with some sort of stub/proxy, if you're interested.
Hu? As I said I am pretty Win32 ignorant.
This has nothing to do with Win32. You simply can not link a Winelib DLL into a Linux app due to a lot of things too tricky to explain here. So there are two possible solutions: -- transform the apps that want to use avisynth into Winelib apps
Can a linux application link with a winlib shared library.
-- run avisynth in a separate process, and devise some sort of RPC mechanism to marshall calls back and forth.
Unless the processes can share memory that will add a huge overhead as video frames will need to be send between processes. -- http://kevin.atkinson.dhs.org
On Wed, 2003-09-10 at 23:36, Kevin Atkinson wrote:
Can a linux application link with a winlib shared library.
Nope. Not yet, anyway.
-- run avisynth in a separate process, and devise some sort of RPC mechanism to marshall calls back and forth.
Unless the processes can share memory that will add a huge overhead as video frames will need to be send between processes.
You can use POSIX IPC to set up SHM segments, that make transfer of large amounts of data easy. There are multiple routes for performing RPC, whether you choose to use DBUS, CORBA, or a custom protocol. Typically domain sockets on Linux are very fast, you don't need to worry about overhead for small amounts of data (like RPCs), the context switch overhead is more problematic. For work that requires very tight synchronization that might be an issue.
On 11 Sep 2003, Mike Hearn wrote:
On Wed, 2003-09-10 at 23:36, Kevin Atkinson wrote:
Can a linux application link with a winlib shared library.
Nope. Not yet, anyway.
-- run avisynth in a separate process, and devise some sort of RPC mechanism to marshall calls back and forth.
Unless the processes can share memory that will add a huge overhead as video frames will need to be send between processes.
You can use POSIX IPC to set up SHM segments, that make transfer of large amounts of data easy.
But can I say I need this block of memory (ie an arbitrary block which already has data in it) to be shared. I want to avoid having to copy large amounts of data. If that can not be done Avisynth will need to be modified to allocate memory for its frames from a specific region of memory. Just to be sure. A normal Linux application CAN NOT load a winlib shared library. Correct? Also, how is the calling of Windows codec done in mplayer, xine, and the like? Could something like that be done. Avisynth has so GUI. -- http://kevin.atkinson.dhs.org
On Wed, 10 Sep 2003 19:13:18 -0400, Sir Kevin Atkinson scribed thus:
But can I say I need this block of memory (ie an arbitrary block which already has data in it) to be shared.
Yes, I think so, the main problem is that setting up a SHM segment is a bit expensive, so you want to reuse it once you're up and running.
I want to avoid having to copy large amounts of data. If that can not be done Avisynth will need to be modified to allocate memory for its frames from a specific region of memory.
That's a possibility, yes, but making avisynth reuse memory like that could improve efficiency anyway as it won't constantly be calling malloc.
Just to be sure. A normal Linux application CAN NOT load a winlib shared library. Correct?
There are hacks around to do it, but all are very specific to that situation (like the Mono patches, mplayer etc).
Also, how is the calling of Windows codec done in mplayer, xine, and the like? Could something like that be done. Avisynth has so GUI.
They basically ripped the Wine DLL/PE loader code and then provided their own stubbed implementations of the code, ie massive hackery. You could go that way if you wanted, but I don't know much about how they did it beyond that. thanks -mike
a rOn Wed, 2003-09-10 at 22:54, Kevin Atkinson wrote:
What is this?
Avisynth needs VC++. My API needs VC++ as it acts as the bridge and must make VC++ calls to avisynth. Everything can be gcc. And in fact I have successfully cross compiled Avisynth filters using my new C interface.
He means that to compile AviSynth as a WineLib app (which is what you want to do, right?) you need to have a standard GNU build system, ie you can build it on Windows using mingw - for the whole app.
After I get Avisynth working I need to be able to call the DLL from Linux. I believe that is possible but I can't seam to find out how after looking over the winelib docks.
This is not currently possible, sorry. How big is this interface to avisynth? The only option ATM is to have it out-of-process, so we'll need to come up with some sort of stub/proxy, if you're interested.
I thought you could load binary DLLs from a WineLib app, but, maybe not. Basically there are "issues" with combining Linux and native-compiled win32 code, for instance you cannot have a normal Linux app then use WineLib to load a binary win32 plugin. Instead, you have to start another wine process then communicate via IPC - sucks :(
On 10 Sep 2003, Mike Hearn wrote:
a rOn Wed, 2003-09-10 at 22:54, Kevin Atkinson wrote:
What is this?
Avisynth needs VC++. My API needs VC++ as it acts as the bridge and must make VC++ calls to avisynth. Everything can be gcc. And in fact I have successfully cross compiled Avisynth filters using my new C interface.
He means that to compile AviSynth as a WineLib app (which is what you want to do, right?) you need to have a standard GNU build system, ie you can build it on Windows using mingw - for the whole app.
I will repeat what I just said: Since it normal interface is VC++ RECOMPILING it under Winelib is NOT really an option as that will mean that existing plugins for Avisynth will no longer work without a recompile. Thus I want to be able to interface Avisynth not recompile it. -- http://kevin.atkinson.dhs.org
On Wed, 10 Sep 2003, Kevin Atkinson wrote:
On 10 Sep 2003, Mike Hearn wrote:
I will repeat what I just said:
Since it normal interface is VC++ RECOMPILING it under Winelib is NOT really an option as that will mean that existing plugins for Avisynth will no longer work without a recompile.
Thus I want to be able to interface Avisynth not recompile it.
We understand that, I was talking about your C interface. That's optional, even that can be compiled with VC++, we'll just run the binaries, no sweat. Our problem is the link between the Linux app and Avisynth, as they have to be two different processes. -- Dimi.
On Wed, 10 Sep 2003, Dimitrie O. Paun wrote:
On Wed, 10 Sep 2003, Kevin Atkinson wrote:
On 10 Sep 2003, Mike Hearn wrote:
I will repeat what I just said:
Since it normal interface is VC++ RECOMPILING it under Winelib is NOT really an option as that will mean that existing plugins for Avisynth will no longer work without a recompile.
Thus I want to be able to interface Avisynth not recompile it.
We understand that, I was talking about your C interface. That's optional, even that can be compiled with VC++, we'll just run the binaries, no sweat.
It MIGHT be possible to make my C interface a winlib by using the functions as it (ie in assembly) and just relinking the lib. Is this even remotely practical and will it help matters at all? -- http://kevin.atkinson.dhs.org
On September 10, 2003 07:16 pm, Kevin Atkinson wrote:
It MIGHT be possible to make my C interface a winlib by using the functions as it (ie in assembly) and just relinking the lib. Is this even remotely practical and will it help matters at all?
It should be practical, but I'm afraid it doesn't help matters much. There is little difference between a PE executable (a native Windows binary) and a Winelib app.
Just to be sure. A normal Linux application CAN NOT load a winlib shared library. Correct?
In general, yes, that is correct.
Also, how is the calling of Windows codec done in mplayer, xine, and the like? Could something like that be done. Avisynth has so GUI.
I don't know, the mplayer guys just copied over some code from Wine, and integrated it into their code with some modifications. -- Dimi.
On Wed, 10 Sep 2003, Dimitrie O. Paun wrote:
On September 10, 2003 07:16 pm, Kevin Atkinson wrote:
It MIGHT be possible to make my C interface a winlib by using the functions as it (ie in assembly) and just relinking the lib. Is this even remotely practical and will it help matters at all?
It should be practical, but I'm afraid it doesn't help matters much. There is little difference between a PE executable (a native Windows binary) and a Winelib app.
Ok than I won't bother.
Also, how is the calling of Windows codec done in mplayer, xine, and the like? Could something like that be done. Avisynth has so GUI.
I don't know, the mplayer guys just copied over some code from Wine, and integrated it into their code with some modifications.
Oh OK. I guess I will have to ask them. For now lets focus on getting Avisynth working.
On Wed, 10 Sep 2003, Dimitrie O. Paun wrote:
On September 10, 2003 11:44 pm, Kevin Atkinson wrote:
For now lets focus on getting Avisynth working.
That's the best thing to do: is the Avisynth binary working under Wine ATM?
I'm sorry, What is Wine ATM? I filed the bug report since it doesn't work well at all under Wine.
On Thu, 2003-09-11 at 00:29, Kevin Atkinson wrote:
I will repeat what I just said:
Since it normal interface is VC++ RECOMPILING it under Winelib is NOT really an option as that will mean that existing plugins for Avisynth will no longer work without a recompile.
But that's also incorrect. Winelib applications are perfectly able to load Win32 binary DLLs. In fact, Wine itself is simply a Winelib application that tells Winelib to load the application specified on its command line. I'd think making Avisynth a Winelib app sounds easier than devising some kind of RPC mechanism, and all existing plugins would still work (without a recompile).
On Thu, 11 Sep 2003, Ove Kaaven wrote:
On Thu, 2003-09-11 at 00:29, Kevin Atkinson wrote:
I will repeat what I just said:
Since it normal interface is VC++ RECOMPILING it under Winelib is NOT really an option as that will mean that existing plugins for Avisynth will no longer work without a recompile.
But that's also incorrect. Winelib applications are perfectly able to load Win32 binary DLLs. In fact, Wine itself is simply a Winelib application that tells Winelib to load the application specified on its command line. I'd think making Avisynth a Winelib app sounds easier than devising some kind of RPC mechanism, and all existing plugins would still work (without a recompile).
The interface is C++. VC++ and G++ API are not compatible. Can wine emulate VC++ API? -- http://kevin.atkinson.dhs.org
BTW: You can find my C API at http://kevin.atkinson.dhs.org/avisynth_c/. Avisynth: http://www.avisynth.org/. And a dead simple program as the test case for the bug http://bugs.winehq.org/show_bug.cgi?id=1707 . -- http://kevin.atkinson.dhs.org
participants (6)
-
Dimitrie O. Paun -
Dimitrie O. Paun -
Kevin Atkinson -
Kevin Atkinson -
Mike Hearn -
Ove Kaaven