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.

A.  DirectShow is in the Windows Platform SDK (now called the Windows SDK or Windows Vista 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 work in the dshow and multimedia areas.  There has been speculation that Media Foundation in Windows Vista will eventually replace dshow for most multimedia tasks but this is still a ways off and whether it will happen is not certain.   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.  Beyond that there are some wrapper classes that are available from some sites (see the Links page).  Filter programming is generally done in unmanaged C++ because of the dshow architecture.  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.

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.


#include <atlcom.h>

...


CComPtr<IGraphBuilder> graph_builder;
HRESULT hr = graph_builder.CoCreateInstance(CLSID_FilterGraph);
if (FAILED(hr))
    return hr;

...

CComQIPtr<IMediaFilter> media_filter(graph_builder);
if (!media_filter)
    return E_NOINTERFACE; // notice that we don't need to Release() graph_builder
hr = media_filter->SetSyncSource(NULL);

return hr; // notice that we don't need to Release() graph_builder or media_filter

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.


#include <atlcom.h>

...


// Find the first <pin> with <direction> on <filter> ? S_OK : E_FAIL
// Note: can return other failed HRESULTs on unexpected events
HRESULT GetPin(CComPtr<IBaseFilter> filter, PIN_DIRECTION direction, CComPtr<IPin> *pin)
{
    if (!pin)
        return E_POINTER;

    HRESULT hr;
    CComPtr<IEnumPins> pins;
    hr = filter->EnumPins(&pins);

    CComPtr<IPin> enum_pin;
    while(pins->Next(1, &enum_pin, 0) == S_OK) {
        PIN_DIRECTION enum_pin_direction;
        hr = enum_pin->QueryDirection(&enum_pin_direction);
        if (FAILED(hr))
            return hr;
        if (enum_pin_direction == direction) {
            *pin = enum_pin; // found match
            return S_OK;
        }

        enum_pin.Release(); // manually release the pin through the CComPtr method (required)
    }

    return E_FAIL;
}

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:

• Old video renderer: standard on Windows versions prior to XP.

• VMR7: standard renderer on XP, unofficially available in Windows 2000 when DX 9.0B is installed.

• VMR9: D3D9 based renderer available with DX 9.0 and later.

• EVR:  currently Windows Vista only.

 

A.  The VMR7 is meant to be compatible with the old video renderer:

• It has the same FriendlyName "Video Renderer" as the old standard video renderer.  Its CLSID is different so you can explicitly insert either one into a graph.  In GraphEdit, it is the "Video Render" that appears first in the Insert Filters list.

• The SDK docs say that VMR7 is only supported on XP, but it is installed on w2k as of DX 9.0b.  Use it on w2k at your own risk.

• Unlike VMR9, VMR7 can support video ports and overlays.

 

A.  Here are the main differences (courtesy of S. Estrop):

• The VMR9 is based on D3D9 and to a certain extent needs D3D9 class
  hardware.

• The VMR9 is available on platforms other than Windows XP.

• The VMR9 has certain video processing features that the VMR7 does
  not have.

• As D3D9 does not have any support for a graphics overlay the VMR9
  can not use overlays.

There is additional information available in the SDK Docs under "Using the Video Mixing
Renderer" and its sub-topics.

 

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. 

• DXSDK: set this to the root DX SDK folder, example: C:\DXSDK
• DSHOWBASECLASSES: set this to the baseclasses folder, example:  C:\DXSDK\Samples\C++\DirectShow\Baseclasses
• MSSDK: set this to the Windows Platform SDK folder, example: C:\Program Files\Microsoft SDK\.
• For all build configurations, add $(MSSDK)/include,$(DXSDK)/include,$(DSHOWBASECLASSES)to Project ð Properties ð C++ ð General ð Additional Include Directories
• For all build configurations, add $(DXDSBASECLASSES)/$(TargetDir),$(MSSDK)/lib,$(DXSDKROOT)/lib to Project ð Properties ð Linker ð General ð Additional Library Directories

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.

• if they are system CLSIDs that you expect dshow to have defined you need to make sure your project has the correct lib files in its Project ð Properties ð Linker ð Additional Dependencies setting for each build configuration.  Common libraries that are required are strmiids.lib and dxguid.lib.  Make sure you also have the Linker's Additonal Library Directories setting set  to include these libraries from the DX SDK (see above)

• if they are your own CLSIDs, you need to include the <initguid.h> file before your CLSIDs are defined in exactly one of your .cpp files; sample code from the MSFT dshow faq:

// Src1.cpp
#include <initguid.h>
#include "MyGuids.h"

// Src2.cpp
#include "MyGuids.h"

// Src3.cpp
#include "MyGuids.h"

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:

#ifndef __D3DRM_H__
#define __D3DRM_H__
#endif

#include <dshow.h>
#include <d3d9.h>
#include <vmr9.h>
#include <qedit.h>
#include <dxerr9.h>
 

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)"
Description: Registering $(TargetPath)
Exclude from build: No

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:

#include <dxerr9.h>

...

HRESULT hr = S_OK;

... something goes wrong ...

CString err(::DXGetErrorString9(hr));
err += ::DXGetErrorDescription9(hr);

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:

1. Download the DirectX 9.0c SDK Extras and extract it to the DirectX 9.0c SDK installation folder.  This will create a subdirectory DirectShow\Developer Runtime\x86\<OS ver>\. In there you can find quartz.dll as well as other DirectShow binaries.  quartz.dll is the main DirectShow binary, but other binaries might output useful debug info and this process should work for them as well.  If you look at the file version properties of quartz.dll you'll see it's described as (debug).

2. Replace quartz.dll in your Windows\system32 system directory with the one from the "Developer Runtime" directory.  Make sure to back up the existing "retail" version of quartz.dll so you can test with it later.

2a. Under Windows 2000 and Windows XP, Windows File Protection will prevent you from simply copying and overwriting the existing version of quartz.dll.  So you'll have to disable Windows File Protection.  I'll let you search Google or your favorite reference source for instructions of how to accomplish this.  It's not a trivial process and involves editing a system file with a hex editor and modifying a registry key.

2b. Once Windows File protection is disabled you'll be able to copy the debug developer runtime version of quartz.dll.

3. Now the only problem is specifying the debug output level you desire.  Previously there was a tab in the DirectX control panel applet with a slider allowing you to configure the output between 0 and 6 (from less to more).  On some SDK installs it seems this tab is either gone or disabled.  However the registry key it stored its state in is still used by both DXDiag and quartz.dll.  Add the following key (if not already there): \\HKEY_LOCAL_MACHINE\SOFTWARE\DEBUG\quartz.dll.  In that key add a DWORD value named TRACE and set the value between 0 and 6.

If you performed step 3 correctly, you can run DXDiag and save its information out to a text file. In that file there's a section that lists the switchable components and their debug levels, you should see the level for DirectShow reflect the value you set for TRACE. Now when you attach your debugger to a process running a DirectShow graph, quartz.dll should output its debug strings into your output window.

As Grant indicated, use his instructions at your own risk.