Is there a C# interface to AviSynth?

[stax76]

Has anybody tried to use AviSynth with C# or VB.NET directly without unmanaged wrapper DLL and without using avifile API?

I've compared the performance of StaxRip's avifile interface with MeGUIs wrapper/direct interface, performance wise there is little to no difference, avifile has hardly features but it's extremely lightweight and I'm a huge fan of lightweight software and avoiding unnecessary complexity.

My avifile class is 260 lines code including .NET typical convenience and all native API definitions and it includes a AviSynth interface called IAvisynthClipInfo to get error messages, it can be accessed from the avifile API, it might be possible to access more interfaces.

If it's even possible to use AviSynth directly I would probably need a complete day building and testing it and since I'm completely happy with the current solution I won't certainly spent a lot of time but if it's already done I would certainly like to take a look.

In case somebody interested seeing my class:

https://github.com/stax76/staxrip/blob/master/General/AVIFile.vb

online converter:

http://codeconverter.sharpdevelop.net/SnippetConverter.aspx

offline converter:

http://www.icsharpcode.net/OpenSource/SD/Download/#SharpDevelop4x

[captainadamo]

What other ways to interface with it are you expecting there to be? Unless you were to port Avisynth to C++/CLI you only have the option of AVIFile interface or an unmanaged-to-managed wrapper (whether that be via PInvoke, C++/CLI wrapper, etc.).

[stax76]

I thought there might be a C or COM+ interface a GUI can use to get basic things like frame count and image frames.

[captainadamo]

I thought there might be a C or COM+ interface a GUI can use to get basic things like frame count and image frames.

Both of which would still require a wrapper. In the case of a COM object you'd have a runtime-callable wrapper to marshal calls. .NET cannot call native code directly. There will always be a wrapper when going between .NET and native code. The only way around that would to be to port and recompile Avisynth as C++/CLI. But that would likely be an enormous amount of effort for no gain.

[stax76]

You are right about how the stuff works under the hood. What I would like to know is if a wrapper library (DLL) or avifile is necessary or if there is a C or COM+ API. BG fan here too. :-)

[Kurtnoise]

Has anybody tried to use AviSynth with C# or VB.NET directly without unmanaged wrapper DLL and without using avifile API?
What's wrong with the wrapper ? I updated few weeks ago the wrapper from MeGUI in order to take account the Avisynth 2.6.xxx and my tests went fine with both Avisynth and Avisynth+ using both x86 and x64 libraries.

I've compared the performance of StaxRip's avifile interface with MeGUIs wrapper/direct interface, performance wise there is little to no difference, avifile has hardly features but it's extremely lightweight and I'm a huge fan of lightweight software and avoiding unnecessary complexity.

My avifile class is 260 lines code including .NET typical convenience and all native API definitions and it includes a AviSynth interface called IAvisynthClipInfo to get error messages, it can be accessed from the avifile API, it might be possible to access more interfaces.

If it's even possible to use AviSynth directly I would probably need a complete day building and testing it and since I'm completely happy with the current solution I won't certainly spent a lot of time but if it's already done I would certainly like to take a look.

Problem with your class is : you cannot be sure that Microsoft will still support avifil32 and/or winmm libraries in the next Windows Operating Systems...in this case, you reach the limit.

[stax76]

What's wrong with the wrapper ? I updated few weeks ago the wrapper from MeGUI in order to take account the Avisynth 2.6.xxx and my tests went fine with both Avisynth and Avisynth+ using both x86 and x64 libraries.

What I do is totally simple, only thing my class exposes is this:

Property FrameCount As Integer
Property FrameRate As Double
Property FrameSize As Size
Property ErrorMessage As String
Property Position As Integer

Function GetBitmap As Bitmap

It might be possible to do that without wrapper library and without avifile API and if not it would be cool if it would be possible in the future. I prefer not using libraries except MediaInfo of course, I think it helps to keep everything small, simple and easy to manage.

Problem with your class is : you cannot be sure that Microsoft will still support avifil32 and/or winmm libraries in the next Windows Operating Systems...in this case, you reach the limit.

avifile is pretty ancient but that's what the WinAPI is, take windows and widgets for instance, I mean it's a C API.

[LoRd_MuldeR]

Avisynth is native/unmanaged code. Consequently you will never be able to call Avisynth directly trough a C# interface without any Interop layer in between. It's just not possible. Unless somebody creates a complete re-write of Avisynth in a managed language (C#, VisualBasic.NET, etc), of course. But that's probably not going to happen anytime soon. So P/Invoke is the way to go.

You can either use explicit P/Invoke directly from C# code, or you can use implicit P/Invoke by writing a "bridge" DLL in managed C++/CLI. Using explicit P/Invoke only works well for plain C interfaces, such as the Win32 API, but it is hardly feasible for C++ interfaces. It is doable, as described here (http://www.codeproject.com/Articles/18032/How-to-Marshal-a-C-Class), but it's not nice and requires at least some modification of the native C++ DLL. This leaved implicit P/Invoke, i.e. writing a "bridge" DLL for Avisynth in managed C++/CLI, your preferred option.

Yes, I know Avisynth also has a plain C interface. But Avisynth' C-interface is just a wrapper around it's underlying C++ interface. If you write a program in plain C (or if you use MinGW/GCC to build your C++ program, which isn't compatible to MSVC C++), this may come in handy. But if you build a P/Invoke wrapper around Avisynth' C-API, you are effectively building a wrapper around a wrapper. Probably not the most best (and certainly not the most efficient) solution.

About COM: Yes, Microsoft.NET also has an Interop layer for COM. You may consider using this, if you have to call a legacy COM component from managed code. But why would you want to go this route for something like Avisynth, which currently doesn't really have anything to do with COM? As Avisynth doesn't have a COM interface, to the best of my knowledge, you would first have to write a COM wrapper around Avisynth, in order to make it available as a COM component. Then this COM component could be called from .NET via the COM-Interop layer. Again you would be building a wrapper around a wrapper. That plus you are adding all the pitfalls of COM. I don't see how this could be a preferable solution...

[stax76]

Why does everybody here think I cannot program? Do you think it's possible to write a application like StaxRip without knowing all this? As QT user you might not be aware of this but COM is all over the place in Windows, even the new Windows Runtime is entirely COM, it's a improved COM version with lessons learned from .NET.

[captainadamo]

No one is saying you can't program. But you're asking a silly question with this. You cannot directly access native code in your .NET program without a managed wrapper (obviously barring programs that output via pipes, sockets, etc.). Period. It doesn't matter if the native code is being accessed via a C or C++ API or through COM.

[LoRd_MuldeR]

Why does everybody here think I cannot program? Do you think it's possible to write a application like StaxRip without knowing all this?

Who said that you cannot program? I certainly didn't. But you asked if anybody has tried to "use AviSynth with C# or VB.NET directly without unmanaged wrapper DLL". And there you got the answer why calling the native Avisynth DLL directly (i.e. without using P/Invoke or a similar Interop layer) from a managed application is not technically possible, why using explicit (http://en.wikipedia.org/wiki/Platform_Invocation_Services#Explicit) P/Invoke (i.e. using P/Invoke directly from C# code) probably isn't the solution that want to go for, and also that implicit (http://en.wikipedia.org/wiki/Platform_Invocation_Services#Implicit) P/Invoke (i.e. writing a "bridge" DLL in C++/CLI) is probably the preferred solution here. If you knew all that already, what answer did you expect? :confused:

As QT user you might not be aware of this but COM is all over the place in Windows, even the new Windows Runtime is entirely COM, it's a improved COM version with lessons learned from .NET.

I don't know how Qt is related to this discussion, but I'm well aware that many technologies in Windows are based on COM (not the Win32 API though, it is plain C). And I also know that the new WinRT-API for Windows Store Apps is based on an enhanced COM version (it has been referred to as "Microsoft's return to COM", as they didn't decide for .NET in this area). I have even developed a COM-wrapper for a commercial product, because the customer asked for a COM-interface. So I think I understand some basics about COM - and about its pitfalls.

Still, this all doesn't explain why you would want to use COM here. It seems like your goal is to call Avisynth from a managed application. That and to keep the required wrapping/interop code to an absolute minimum. Using implicit P/Invoke is probably as close as you can get to this goal, as it "only" requires one bridge DLL, which glues Avisynth' native C++ interface to the C# world. And it does not require any changes in Avisynth itself. At the same time, going the COM route would require writing a COM-wrapper around Avisynth - which is probably at least as much work as writing a C++/CLI "bridge" DLL. And even if you had this COM-wrapper, you would still have to rely on an additional Interop-layer (i.e. the Microsoft.NET COM-Interop) for interacting with the COM object from the managed application. So, to my understanding, the COM solution means at least the same amount of work and twice the number of Interop layers. Doesn't sound like an attractive solution to me...

[stax76]

@captainadamo

Please tell me then at least what the silly parts were, maybe I wasn't clear, maybe I mixed terms, I would like to know in order to make it better next time.

[captainadamo]

@captainadamo

Please tell me then at least what the silly parts were, maybe I wasn't clear, maybe I mixed terms, I would like to know in order to make it better next time.

My post explicitly explained that. Your post is like asking: "How can I access native code in Java without having to use JNI?" The answer to that and your question about not needing a managed wrapper is: You can't. It doesn't matter what the interface is, you need a managed wrapper (whether it be autogenerated or manually created).

The only way to be able to directly access Avisynth via .NET with no wrappers, etc. would be to port it to C++/CLI and compile it for the CLR. Any other interface for Avisynth is going to require a wrapper of some kind.

[stax76]

The misunderstanding is as it seems in my first sentence "Has anybody tried to use AviSynth with C# or VB.NET directly without unmanaged wrapper DLL and without using avifile API?", in particular the word "directly" caused the confusion, honestly I don't see such I big problem, calling C is P/Invoke, pretty basic knowledge, I think of calling COM+ as P/Invoke too, if that's actually the precise term I don't know, for me it just calling native code, that the CLR uses runtime callable wrappers for COM is also pretty basic knowledge. I just assumed that everybody knows that everybody knows it. The question was just using AviSynth without wrapper DLL.

[captainadamo]

The only ways to access Avisynth from .NET are the following:

1) P/Invoke wrapped calls to its native interface (whether in a separate wrapper DLL or in an internal class to your project)
2) AVIFile API.
3) C++/CLI wrapper.

Even if there were a COM interface you'd still have to create a wrapper in order to use it that way. Unless you're willing to port Avisynth to C++/CLI you cannot access it some other way from .NET.

[OvejaNegra]

I know this is out off subject, but in my limited time i wrote a tool (on vb.net) for helpping me with tivtc.
Your class was very usefull for opening AVS files and retreiving frames, thank you.
IF, and only IF you have the time to expand it to support filter parameter changes on the fly (like yatta) that would be VERY usefull.

Thanks again.

I struggled with this once but i lack the skills and time:
http://forum.doom9.org/showthread.php?t=165330

Thanks again.