Experimental DirectShow Source Filter in C# PDF Print E-mail

This document describes the steps and code needed to implement a DirectShow source filter in C#. The code itself can be found in the following zip file. This zip file also contains a Readme.txt file which explains how to install the filter in your system.

The strategy we use to implement a DirectShow filter in C# relies on having a C++ class that contains a pointer to a managed object which implements our filter. The C++ class just forward all the processing to the managed object. In order to achieve this, we can use a sample from the SDK and modify the code or use a Wizard (usually derived from the original Wizard designed by Ross Cutler) that generates a skeleton for the classes needed by our filter and the VS project settings. For the CsYuv filter, I've used Cutler's Wizard and in this filter we'll modify the project and code for the Ball filter from the DirectShow SDK.

Make sure that you can build the Ball filter sample. If you just want to test the filter, then build the code in the zip file and follow the steps in the ReadMe file to install it. If you want to create your own source filter, now I'll describe the steps needed to modify the Ball sample project and after that, we'll look at the code.

First, maybe you'll want to make a backup copy of the Ball sample filter directory. Then in VS, delete all the files of the project and add the header, cpp, and def files from the zip archive to the project. This is the code for the C++ wrapper. Then add a new C# Class Library project to the solution, and replace the files in the newly created project by the cs files in the zip archive. This is the code for our managed class that implements the filter functionality.

Since you'll want to install the assembly for the filter in the GAC, you'll need to sign the assembly (e.g. type "sn -k key.snk" at the prompt of a VS shell). Note that the open-source DirectShowLib should also be in the GAC for the filter to work correctly.

Some of the Ball sample project settings have to be modified in order to embed a pointer to a managed object. We'll describe these now. From the C++ project settings of the solution, go to the "C/C++/Precompiled Headers" page and choose "Not Using Precompiled Headers". Go to the "C/C++/General" page and choose "Assembly Support (/clr)" for the field "Compile As Managed". Also on the same page, enter the path to the managed assembly in the field "Resolve #using References". If the linker complains about a missing __CorDllMain function, toy with the /NODEFAULTLIB under Linker/Input/Ignore All Default Libraries".

We are now ready to look at the code. Let's start with the header file for the C++ project. The top of the file shows the following: 

  1.  
  2. // let the filter use managed code
  3. #using <mscorlib.dll>
  4. // this is the assembly for our filter
  5. #using <csfilter.dll>
  6. //needed for the gcroot template
  7. #include <vcclr.h>
  8.  
  

Since we are embedding a pointer to a managed object in a native C++ class we need to tell the compiler about it. So we have the references to the "mscorlib.dll" and our assembly "csfilter.dll". Then we add an include file for the "gcroot" template that allows us to embed a pointer to a managed class. At the bottom of the header file, we have the following declaration: 

  1.     
  2. // we embed a pointer to our managed class
  3. gcroot< CsFilter *> m_pCsFilter;
  4.  
  

The rest of the header file is almost identical to the Ball source header file. Let's now look at the cpp file, it's also very similar to any other source filter implementation. In the constructor for the source filter output pin, we define our managed object: 

  1.     
  2. // define the pointer to our managed object 
  3. m_pCsFilter = new CsFilter(m_iImageWidth, m_iImageHeight);
  4.  
  

Notice that our managed object is member of a class derived from CSoureStream: the base class for the output pin on a source filter which is derived from the CAMThread. So, the native streaming thread manipulates a pointer to a managed object. Then the implementation of the all the member functions of the C++ class for the source filter output pin just calls a corresponding method on our managed object, for example: 

  1.  
  2. HRESULT CPushStream::FillBuffer(IMediaSample *pms)
  3. {
  4.  CheckPointer(pms,E_POINTER);
  5.  ASSERT(m_pCsFilter);
  6.  CAutoLock cAutoLockShared(&m_cSharedState);
  7.  return m_pCsFilter->FillBuffer( (void *) pms );
  8. } // FillBuffer
  9.  
  

We marshal all our arguments as IntPtr because we assume this is the option that produces the smallest overhead but we haven't done any actual profiling. We are now ready to look at the C# implementation of our source filter. The CsFilter.cs file starts with (after some standard using directives): 

  1.  
  2. using DirectShowLib;
  3. using IMemTypeLib;
  4.  
  

I've mentioned that the open-source DirectShowLib is needed. The IMemTypeLib was created using the techniques described in the "Cooking a custom library" tutorial but where the created assembly was disassembled using the "Reflector" utility (and the code was cut and pasted from "Reflector" panel to the file "IMemTypeLib.cs").

I won't write a DS source filter tutorial but I'll notice the differences between a typical DS source filter and the implementation in C# of this one. This experimental filter just support one media type, so we have implemented the GetMediaType method that requires a single argument. The method starts as follows: 

  1.     
  2. public int GetMediaType( IntPtr mtPtr )
  3. {
  4.   // get our media type struct
  5.   AMMediaType pmt = (AMMediaType)Marshal.PtrToStructure( mtPtr, typeof(AMMediaType) );
  6.   // free the format type
  7.   DsUtils.FreeAMMediaType( pmt );
  8.   // define a video info struct
  9.   VideoInfoHeader vih = new VideoInfoHeader();
  10.  
  

First we marshal our media type structure and free its format field, then we'll fill a VideoInfoHeader structure and the fields of the media type. The interesting ones are: 

  1.       
  2. // 88 size of videoinfoheader struct
  3. pmt.formatSize = 88;
  4. // allocate native mem for the vih
  5. IntPtr vidBuffer = Marshal.AllocCoTaskMem( 88 );
  6. pmt.formatPtr = vidBuffer;
  7. // copy vih and mt into native heap
  8. Marshal.StructureToPtr( vih, vidBuffer, false );
  9. Marshal.StructureToPtr( pmt, mtPtr, false );
  10.  
  

We allocate memory from the native heap and make the formatPtr of media type points to it. Then we copy in the native heap the two structures. The DecideBufferSize method configures the memory allocator, again we'll concentrate on the differences when done in C#. The method starts with: 

  1.     
  2. public int DecideBufferSize(IntPtr PtrAlloc, IntPtr PtrProperties )
  3. {
  4.   // grab a "pointer" to the allocator
  5.   IMemAllocator pAlloc = (IMemAllocator)Marshal.GetObjectForIUnknown( PtrAlloc );
  6.   // bring in the allocator property from the native heap
  7.   _AllocatorProperties pProperties = (_AllocatorProperties)
  8.     Marshal.PtrToStructure( PtrProperties, typeof( _AllocatorProperties ));
  9.  
  

First, we get the interface "pointer" for the memory allocator which is created by the base classes before a call to the DecideBufferSize method is made. Similarly, we get the allocator properties required by the downstream filter through interop using the second argument to the method. After filling some properties, we release the memory allocator pointer: 

  1.       
  2. // release our interface
  3.   Marshal.ReleaseComObject( pAlloc );
  4.   return NOERROR; 
  5. } 
  6.  
  

The FillBuffer method is where we draw our frame, the method receives a pointer to a media sample. 

  1.     
  2. public int FillBuffer( IntPtr PtrMS )
  3. {
  4.   // grab our media sample
  5.   IMediaSample ms = (IMediaSample)Marshal.GetObjectForIUnknown( PtrMS );
  6.   // fix our timestamps
  7.   DsLong start = new DsLong( FrameCount * FrameInterval );
  8.   DsLong end = new DsLong( start + FrameInterval );       
  9.   
  10.   // set the timestamps and make it a keyframe
  11.   ms.SetTime( start, end );
  12.   ms.SetSyncPoint( true );
  13.   
  14.   // draw what we want on the frame
  15.   
  16.   // first get a pointer to the ms data
  17.   IntPtr scan0;
  18.   ms.GetPointer( out scan0 );
  19.   
  20.   // make a bitmap object out of it 
  21.   bitmap = new Bitmap( Width, Height, Width*3, PixelFormat.Format24bppRgb, scan0 );
  22.   // grab a gfx object
  23.   gfx = Graphics.FromImage( bitmap );
  24.   // draw a red backgroud
  25.   gfx.Clear( Color.Red );
  26.   // write the frame count
  27.   gfx.DrawString( FrameCount.ToString(), font , brush, 10.0f, 10.0f );
  28.   
  29.   FrameCount++;      
  30.   
  31.   // do some cleanup
  32.   bitmap.Dispose();
  33.   gfx.Dispose();
  34.   Marshal.ReleaseComObject( ms );
  35.   return NOERROR;
  36. }
  37.  
  

We marshal the media sample, then prepare some timestamps and indicate that we have a keyframe since our samples are not compressed. After getting a pointer to the buffer data, we turn it into a bitmap object and use its "device context" to draw the backgroud red and display the frame count. When we're done we do some cleanup.

The method OnThreadCreate just reset our frame counter to 0.

As the title of this document stresses, this is an experimental filter. While MS doesn't recommend using managed code for filters, now at least, we have a basis for comparaison. I have delayed posting this code because I believe that the C++ code should be hidden in some kind of wrapper but I haven't found a good way to do this.



Bookmark it...
Digg!Reddit!Del.icio.us!Google!Facebook!Slashdot!Technorati!StumbleUpon!Newsvine!Furl!Yahoo!Ma.gnolia!
 
< Prev
[ Back ]
Joomla Template by Joomlashack
Joomla Templates by JoomlaShack Joomla Templates by Compass Design