Thursday, July 10, 2008

Using Directshow in .Net : DirectshowNet vs. C++/CLI

There are two usable option for using Directshow in .Net so far (excluding the abandoned-managed-directshow) :

  1. Purely in .Net using DirectshowNet : code -> directshownet
  2. Get a little bit dirty using C++/CLI : code -> c++/cli bridge-> directshow
Having tried both, I prefer using the second one for several reason :
  1. You don't need to translate between what's on the directshow manual with what you need to write. On many cases you could just paste and code many boiler plate code as is and it just run. Using directshownet you have to do some mental gymnastic to do it.
  2. Debugging would be more comfortable in native language.
  3. You can hide the complexities of Directshow/COM exclusively in native code and have your managed code stay clean. You'll most likely end up with three layer modularisation : .net code -> c++/cli -> native c++ that access directshow. In the middle layer (c++/cli) you could provide your managed code with clean interfaces using native .net construct e.g: Properties, Event Handler.
However, the downside is quite obvious : you need to be comfortable with C++.

To sum up : You'll do better using C++/CLI when :
  • You already familiar with C++
  • Want to make application rapidly utilizing .Net
Although for those who still does not like to bother with C++/C quirks and overhead/headaches e.g: builds, linking, compilations, DirectshowNet route can provide more convinience with a "little" cost of translation and more "shady" debugging.

The better option from all these would be a .Net library that encapsulate Directshow in a more .Net-friendly way, not just a collection of "typedef"s. An even better one would be a much friendlier multimedia framework (assuming currently directshow's existing codecs and filters ported there too :) ).

6 comments:

Manelito said...

Do you know any directshow lib or class that works natively with c++/cli?

Hafiz said...

I am not sure what you mean exactly, but all directshow lib itself can be used in C++/CLI directly.

Manelito said...

I would say a nice DirectShow C++ class definition... In the examples that I have seen there isn't a C++/CLI class definition only a dumb of old C style declarations.

Hafiz said...

If you work in .net you could try DirectshowNet mentioned above :

http://directshownet.sourceforge.net/

If you work in native or mixed managed in C++ or C++/CLI then you could use Directshow library and all it's definition directly, there's no translation/redefinition needed.

alexb said...

hi,
I have try the C++/CLI approach for all reason that you have write BUT,
I meet some problem of "ambiguous symbol" like in the following...

Have you an advice to solve this issue.

Alex.

error C2872: 'IServiceProvider' : ambiguous symbol
\windows sdk\v6.1\include\servprov.h(53) : System::IServiceProvider IServiceProvider'
or 'c:\windows\microsoft.net\framework\v2.0.50727\mscorlib.dll : System::IServiceProvider'

and also * vs ^ notation:
\windows sdk\v6.1\include\servprov.h(96) : error C3699: '*' : cannot use this indirection on type 'IServiceProvider'
compiler replacing '*' with '^' to continue parsing

Hafiz said...

Hi Alexander,

For the first problem, try not to open System namespace from .Net in the code (using namespace System;), instead resolve the use directly (System::X)

For the second one, you can't mix native pointers with managed one. Also if you use '*' as a member variable in managed C++, it's not native pointers rather interior pointer. They are quite similar but not exactly the same e.g: you can't pass them to function that expect address to native pointer in the argument. However you could assign native pointer to interior pointer which is useful for workarounds for some cases.