Came across an old project where I had to solve this need, and thought I'd archive it on here for search engine purposes. This can be useful for scenarios like corporate training video directories, where you let the trainers upload videos and it automatically creates a thumbnail for clients to browse in a webapp, for example.

The first thing you'll need is an interop assembly to allow you to use the DirectShow COM objects from within .NET. You could either add a COM reference to your project, or better still use the command line tlbimp.exe framework utility to create the interop - the latter is preferred, as you'll want a strongly named interop assembly, which you can accomplish by specifying a keyfile with the tlbimp.exe /keyfile: parameter (specifying a key file that you created with the sn.exe framework utility). Add the newly created interop assembly as a reference in your project - barring specifying parameters otherwise, it'll be called Interop.DexterLib.dll, and once referenced will appear in the references as, of course, Interop.DexterLib.

There are a couple of structures that we need to define as we'll need them to communicate with DirectShow.

  [StructLayout(LayoutKind.Sequential)]
  struct element_RECT
  {
    public int left;
    public int top;
    public int right;
    public int bottom;
  }

  [StructLayout(LayoutKind.Sequential)]
  struct element_VideoHeaderInfo
  {
    public element_RECT rcSource;
    public element_RECT rcTarget;
    public UInt32 dwbitrate;
    public UInt32 dwbiterrorrate;
  }

The following code presumes that a couple of variables exist (for instance as parameters to a function)

• videoFilename (string) - The string full path and filename of the source video
• videoOffset (float) - How many seconds from the beginning of the video to pull the frame
• bitmapDestination (string) - The full path of where to store the extracted file. The MediaDet object requires that the extracted file be stored as a file

In your extraction function, create a MediaDet instance, set the source video file path via the Filename property, and search for a video stream (there can be multiple streams. We search for a video stream by looking for one identified by the GUID 05589f80-c356-11ce-bf01-00aa0055595a). The following presumes that the unit has a using Interop.DexterLib; in it.

MediaDet mediaInt = new Interop.DexterLib.MediaDet();
mediaInt.Filename = videoFilename;
   
bool videoStreamFound=false;
_AMMediaType oMediaType = mediaInt.StreamMediaType;

System.Guid videoHeader = new
                  System.Guid("05589f80-c356-11ce-bf01-00aa0055595a");
   
int streamCount = mediaInt.OutputStreams;
for (int counter=0;counter< mediaInt.streamCount; counter++)
{
 mediaInt.CurrentStream = counter;
 oMediaType = mediaInt.StreamMediaType;
 if (oMediaType.formattype == videoHeader)
 {
  videoStreamFound= true;
  break;
 }
}

Notice that we're setting the CurrentStream property on each iteration, so when a video stream is found, the MediaDet object will already have it selected as the active stream.

If we found a video stream in the file, retrieve the properties of the video frame so we can grab a full frame, and then direct it to save a frame at the specified time offset to our specified destination file. 

if (videoStreamFound)
{
 element_VideoHeaderInfo *header =
          (element_VideoHeaderInfo *)(oMediaType.pbFormat.ToPointer());
 mediaInt.WriteBitmapBits(
                    videoOffset,
                    oHeader->rcSource.right-oHeader->rcSource.left,
                    oHeader->rcSource.bottom-oHeader->rcSource.top,
                    bitmapDestination);
 Marshal.FreeCoTaskMem((System.IntPtr)oHeader);
}

Now ensure that the COM object is predictably freed now.

Marshal.FinalReleaseComObject(mediaInt);

Note that there are pointers (scary!) used above, so this code needs to be compiled with /unsafe. Don't worry - It's safe.

This technique works for pretty much any non-DRM multimedia file that contains a video stream, for which there is a DirectShow compatible codec installed on the system.

One note about this entry - I would use the PRE element and layout the code better, however Radio Userland exhibits a trait that drives me nuts with software: It is too clever, in a way that is often very detrimental. From removing attribute formatting, to completely reformatting PRE blocks, to auto-linking links that it shouldn't link, I seem to spend too much time trying to avoid it's "helpful" logic. This seems to be the case with too much software out there.

"It appears that you're writing a letter..."

Tagged: [.NET], [NET], [Software Development], [Programming], [Software-Development]

Back on September 13th I declared that SVG was a dead technology. Since then, the release of Firefox 1.5, along with the free-as-in-beer state of Opera - both featuring native SVG rendering engines - has really spurred SVG activity. I've been getting dozens of SVG related search hits here a day, and that's for an old article that I wrote back in 2002. It could be that the community finally caught onto this fantastic technology.

SVG might not be dead afterall.

Tagged: [SVG], [Programming], [Software-Development]

One of the benefits of being in the industry for a few years (I've been professionally developing and providing system consulting services for 12 years now, and of course was in the amateur ranks for a decade before that) is that you get to see history revised firsthand. This is especially true in the web app world, where the history of the platform is being rewritten by people who want to change it for their own gain, or who simply weren't involved in the industry and thus have incomplete knowledge, rewriting it purely out of ignorance.

A frequent loser in this rewriting is Microsoft: Whether it's imagining Microsoft to be a web app laggard (I was developing for the Microsoft technology stack, making web apps that blow away what people are amazed by today...6 and 7 years ago. Microsoft was a web technology superstar, but because most shops remained committed to fat apps, or wanted cross platform capabilities, few embraced their innovations), or having no influence (a lot of the current platform was either invented or implemented first by Microsoft. From IFRAMEs to most of CSS to XMLHTTP. Others like behaviors and filters died an ignoble death). While Microsoft is far from a perfect netizen, a lot of what they did has significantly and positively affected the web that we use today.

Rumor has it, and I am prone to believing it, that the web app platform was getting so powerful that the Internet Explorer team was disbanded: It was becoming capable enough that many corporations were switching many of their in-house applications to web apps, and the worry was that even with IE-only web apps, tied to IE-specific functionality, it was just a short jump to making them cross-platform (or allowing for parallel, slightly less capable cross platform options), dramatically reducing the lock-in of the Windows platform.

In any case, one Microsoft technology that is being particularly maligned is the infamous ActiveX.

Of course the term itself is a bit of a mess, and offers a classic example of Microsoft marketing gone awry (just like the disaster of naming that was .NET. If people weren't fired over that debacle, then justice wasn't served) - According to some Microsoft sources, ActiveX was a set of interfaces that could be added to a COM (Component Object Model) object to allow it to interact with the interface of an application. Generally encapsulated in .OCX files (Ole Custom Controls), these provided a replacement to the venerable VBX controls of yesteryear, providing a binary, language-neutral visual control that could be used in any ActiveX environment: Whether a Visual Basic app, a Delphi app, a MS Access form, an Excel worksheet, or a Visual C++ app, you could make use of a single ActiveX control. At one gig we needed two synchronized animated graphs showing engine performance for a tradeshow presentation - one quick Delphi ActiveX control later, and it was in the presentation (integrated right in the PowerPoint) and working great. That was the power of ActiveX.

ActiveX was also the technology behind plug-ins in Internet Explorer - Instead of begging the Netscape cabal to let them into the inner circle of Netscape plug-ins, ActiveX controls could be created by anyone and used in web pages (presuming some security hurdles were jumped, such as getting the controls signed). It was a free and open world for web extensions, and of course they proliferated by the thousands, though only a few remained when the dust settled.

Another definition is that ActiveX refers simply to COM controls themselves - if it's a COM control, then it's an ActiveX control. Another variant is that ActiveX refers to COM controls marked "Safe For Scripting".

In any case, COM was a great advance for the platform. It provided high performance, binary, language neutral, object-oriented controls that could be used throughout the system in a truly modular fashion. They could even be proxied across systems, or hosted in service modules (MTS which became component services).

Seeing the value of this powerful, extensible, system-wide technology, the Internet Explorer team decided to implement a lot of its functionality via this mechanism - So long as you configured it with the proper registry entries, and optionally implemented an interface stating its safety level, these components were usable from scripting in Internet Explorer. An obvious, and incredibly powerful, example was the use of the XMLHTTP component (a part of the MSXML library, which itself is a variety of COM controls) from within Internet Explorer. Independently both sides could be upgraded and changed, automatically benefitting the other side where desired. If you implemented visual controls, you could implement specific functionality that couldn't be handled with traditional web technologies in something like Delphi or MFC/C++, and gain all of the advantages of the web model (such as the document flow layout) alongside extremely rich controls.

It helped a lot of shops start transitioning to web applications long before the web platform could do it on its own.

The problem with ActiveX, and the main reason why it's maligned (apart from the platform lock-in), is that several controls that were marked safe for scripting were not, in fact, safe for scripting: Either they were programmed sloppily, and opened holes for buffer overflow and other nefarious activities, or they had dangerous operations that should never have been allowed from within Internet Explorer. Whatever the case, they opened holes that shouldn't have been opened.

Specific implementations gave the whole technology - a modular, high-performance and highly extensible system - a bad name. It could be said that it deserved it, given that it didn't sandbox the operations of the scripted object, but that's an implementation detail: At the core it really is a fantastic foundation.

Tagged: [Software Development], [Programming], [Software-Development], [ActiveX]