DirectShow Frequently Asked QuestionsBelow are answers to some questions that get asked repeatedly in the public forums. If you don't find the answer you're looking for, see the Where to Get Help page. The questions are divided into these categories:
A. The dshow components are not included in the April 2005 and later DirectX SDKs at all (you can get an earlier version from the link on my downloads page). As of the October 2004 Update, the dshow components are in the DirectX Extras download and there is a separate CHM file in that download with the dshow SDK docs. Please see the next question for more info on this subject and the Debugging section for more information on the debug runtime.
Q. Where is DirectShow and what is its future? (you may have read that it is legacy component)
A. DirectShow is in the Windows Platform SDK (now called the Windows SDK). The first PSDK to include dshow is the Windows 2003 SP1 release (see the Links page). A reason given for this change is that DirectX will concentrate on the gaming and graphics area. Does this mean that dshow is no longer being developed? No. Although, Microsoft does not generally announce plans for future releases, there is continued maintenance work in the dshow and multimedia areas. There new SDK called Media Foundation in Windows Vista will eventually replace dshow for most multimedia tasks. There are still many applications that use dshow's precursor Video for Windows. MS's record on not breaking compatibility is better than most operating systems. If you're developing for pre-Vista versions of Windows, dshow is currently your best bet for multimedia development. There are no announced plans to make Media Foundation available on Windows versions prior to Vista.
A. Microsoft provides an AudioVideoPlayback object for managed code. Filter programming is generally done in unmanaged C++ because of the dshow architecture and its reliance on the baseclasses. Microsoft has not announced any plans for additional support for managed code in dshow. TMH's opinion is that additional support from Microsoft is unlikely to happen. The best resources for managed development for these SDKs is:
A. Primarily, the reason is historical. When I first started posting in the Microsoft newsgroups I used my name. It was confusing because there was another regular poster with a similar name and we got mixed up. It's not too difficult to find out my name if you're curious. It's not a big deal, plus it's kind of fun having an online alias.
A. Yes, there is. You can download it here. It requires VC7.1. There is an older version for VC7 on the CD in the Mark Pesce book. It does not have all the features included in the latest version. See the release notes for details. VC8 is not currently supported because the wizard model was changed.
A. Releasing interfaces properly in your code is much easier if you use the smart COM pointers CComPtr and CComQIPtr. Your code will also look cleaner.
One of the few times you explicitly need to release interfaces when working with dshow and smart COM pointers is when you are enumerating through a collection of interfaces (examples: pins, filters, monikers). In this case, you must call the ".Release()" method which is on the smart COM pointer rather than the "->Release()" method on the interface to ensure that the reference count is correct. If you call the latter, there will be an additional release in the smart COM pointer's destructor and the reference count will be invalid. The code snippet below illustrates this. It is a rewrite of the GetPin example in the SDK docs (with an error fixed). Notice that it is simpler, shorter and more elegant.
A. The cameras are putting the fw bus in S100 mode (100 Mbps). This isn't anything you can change. According to the spec, there is slightly more than 50 Mbps taken by each camera (for data + overhead). The MS driver is designed to recognize this and only accept one connection. There isn't an error message returned explaining this. The reason it sometimes works is that fw is peer-to-peer and the root device can be one of the cameras rather than the computer/card. The camera may not enforce the limit and the actual data streamed may not go over the 100 Mbps limit. TMH verified this with the MSFT engineer responsible for testing DV cameras there. For consistent results, you need one fw controller per camera. You can't control which device is the root device.
A. There are two standard interfaces IAMStreamConfig and IAMCameraControl. The first interface is used to set the resolution and media type on a capture device. The second supports setting options like brightness and contrast. Both interfaces have methods to return a range of values that are supported. Not all capture devices support these interfaces. See the SDK docs for implementation details.
A. There are four video renderers:
A. The VMR7 is meant to be compatible with the old video renderer:
A. Here are the main differences (courtesy of S. Estrop):
There is additional information available in the SDK Docs under "Using
the Video Mixing
A. Usually when we see the undefineds related to methods or constructors with char-type variables in them it is one of two issues:
A. Visual Studio 6 support was removed in the October 2004 Update SDK. This does not mean you cannot use this SDK but there are no .dsw or .dsp files included in the SDK and there are some header file incompatibilities that require workarounds. Recommendation: if you're going to continue to use dshow, upgrade to VS.NET, otherwise download the DX 9.0b SDK if it's still available from Microsoft Downloads (see Links page).
A. VC 8 compatibility is not complete in the Windows 2003 SP1 Platform SDK from Microsoft. There are guidelines for fixing the issues in Mike Wasson's blog. There are Vista Windows (Platform) SDKs available to MSDN subscribers. These provide updated headers. Note that the naming of the PSDKs is confusing: the name is the most recent Windows version supported but earlier versions are also supported. See the release notes for a particular PSDK for details. Also, see my downloads page for Visual Studio projects that are not included with some versions of the newer SDK (thanks Chris and Iain).
A. As with VC6, there is no reason you cannot other than you may run into incompatibilities with header files or libraries. TMH has not seen any problems reported thus far. Microsoft is no longer testing the SDK on w2k but the runtime is still supported on w2k.
A. Two words: environment variables. First, make sure you have built the dshow base classes in the dshow samples folder for each configuration (release, debug, release unicode, debug unicode) per the dshow SDK release notes. Then, define two environment variables as described below and use them in all your projects. Use Start -> My Computer -> Properties (right-click) -> Advanced -> Environment Variables and set them in the User Variables section.
You will have to restart Visual Studio for the environment variables to take effect after creating or changing them. Compiling and linking will be much simpler though :)
A. There are two potential resolutions to this problem.
A. You probably also have <qedit.h> in your include file list. This is a known issue and the workaround is to split your code that uses VMR9 and the code that uses DES and related functions like IMediaDet into two separate source files. This means that you can't put either header file in a precompiled header such as stdafx.h.
An alternative solution was posted on the newsgroups by chadderack. He uses the #define below so that the conflicts are avoided:
A. With VC7.0 and later, there is a Register Output option on the Linker page of the project's properties. This is the simplest method.
With earlier versions of VC, select all build configurations and add a post-build event (Project -> Properties -> Build Events -> Post-Build Event):
Command Line: regsvr32 /s "$(TargetPath)"With this technique, when a filter is linked it will automatically register itself and replace any filter previously registered using the same CLSID. If you use TMH's filter wizard, self-registering is added automatically to the filter project.
A. You can add code to your application to add your constructed filter graph to the Running Object Tablet (ROT). There is code in several of the samples which illustrates how to do this (see REGISTER_FILTERGRAPH #ifdef'd sections in the Text9 sample). Remember to #define this for debugging only, otherwise your customers will be able to do this with your application. Also, several people have reported side effects when the graph is in the ROT. For this reason, only enable the ROT code when you need it. When you run GraphEdit, use Ctrl+G to show the graphs registered in the ROT. If your application code to remove the graph from the ROT doesn't get called you will see ghost entries in the list.
A. In Visual Studio go to Project -> Properties -> Linker set "Register output" to "Yes" for the Debug build of the filter. That will call regsvr32 when the filter is linked. Set Project -> Properties -> "Debugging Command" to the full path of GraphEdt.exe (or the other application which uses your filter). Set a breakpoint or several in your filter. Launch the project, then add your filter to the graph and run it if necessary to hit the first breakpoint. Voilą, your breakpoint will be hit.
A. HRESULTs fall into two categories: error codes and success codes. You can use the FAILED(hr) and SUCCEEDED(hr) macros to differentiate between them. The most basic return values are S_OK and E_FAIL. To get more information you can call:
Remember to include dxerr9.lib in your project's settings. There are version 8 values in <dxerr8.h> and dxerr8.lib if you are using a DX 8.x SDK. There is also a utility program in the SDK to look up errors. If you use it, remember to convert the value to hex or include the negative sign if using a decimal value.
A. The dshow debug runtime went missing in the Summer 2004 SDK update but was reintroduced in the December 2004 SDK update in the Extras folder. The reason it went away was it didn't meet new stringent internal security guidelines MSFT put in place. Here are instructions from Grant in the public newsgroups (not tested post-XP SP1, a checked debug build install from MSDN is probably the best way to get the debug runtimes going forward but TMH has not tested this):
Here's how I was able to install it under Windows XP SP1 (I'd guess this process should work for other Windows versions), your mileage may vary and I won't be responsible for any damage done to your system by following these instructions. They're for reference only:
As Grant indicated, use his instructions at your own risk.
Copyright © 2010 by The March Hare. All Rights Reserved. Last modified: August 07, 2010