The case of incorrect behavior of stock DirectX Media Objects

Since Microsoft Windows Vista, Media Foundation API offers a set of convenient Digital Signal Processors for video and audio processing. These include conversion helpers for video and audio, dual interfaced as Media Foundation Transforms (MFTs) and DirectX Media Objects (DMOs). Earlier posts shed some light on DMO interfaces, and use of DMOs in DirectShow graphs with the help of DMO Wrapper Filter.

It appears, however, that some of the stock DMOs are exhibiting unexpected behavior in part of setting media types for input and output streams. IMediaObject::SetInputType and IMediaObject::SetOutputType methods are not only expected to set media types, but also test and clear them depending on flags passed in arguments:

There are three modes defined, depending on value of dwFlags parameter:

  • 0 – [test and] set media type
  • DMO_SET_TYPEF_TEST_ONLY – test only media type
  • DMO_SET_TYPEF_CLEAR – clear media type already set

When the DMO backs a DirectShow filter through DMO Wrapper Filter, there might be (and there definitely are in case of interactive operation in GraphEdit-like application) tests and sets, and resets too during pipeline building stage, and correct support for all flags is important for proper operation.

Unfortunately, some DMOs do not honor the flags and implement incorrect behavior. In particular,

  • Color Converter DSP (CLSID_CColorConvertDMO) does not do it right withDMO_SET_TYPEF_TEST_ONLY and is unable to test media types – instead it sets them
  • Video Resizer DSP (CLSID_CResizerDMO) does it even worse: it ignores both DMO_SET_TYPEF_TEST_ONLY and DMO_SET_TYPEF_CLEAR and attempts to set the media type even if the request was to clear

The project below (SVNTrac) demonstrates the problem in action.

An attempt to test and print current media type shows that testing actually sets the media type:

const HRESULT nTrySetInputTypeResult = pMediaObject->SetInputType(0, &InputMediaType, DMO_SET_TYPEF_TEST_ONLY);
_tprintf(_T("nTrySetInputTypeResult 0x%08x\n"), nTrySetInputTypeResult);
PrintInputType(pMediaObject, DMO_E_TYPE_NOT_SET, _T("we only tested, we did not set it"));


nTrySetInputTypeResult 0x00000000
nGetInputCurrentTypeResult 0x00000000 <<--- Incorrect, we only tested, we did not set it
Input: biWidth 1920, biHeight 1080

An attempt to clear produces a failure, since it is treated as an attempt to set and no real media type was passed as an argument:

const HRESULT nResetInputTypeResult = pMediaObject->SetInputType(0, NULL, DMO_SET_TYPEF_CLEAR);
_tprintf(_T("nResetInputTypeResult 0x%08x%s\n"), nResetInputTypeResult, FAILED(nResetInputTypeResult) ? _T(" <<--- Incorrect") : _T(""));


nResetInputTypeResult 0x80004003 <<--- Incorrect

The problem is posted to Microsoft Connect as Digital Signal Processors do not honor flags arguments on DMO interface IMediaObject when setting input/output types where you can upvote it if you suffer from the bug, and also read back from Microsoft when they follow up.

Utility Clearance: Enumerate Audio ‘MMDevice’s

The utility and code does straightforward enumeration of MMDevices (Vista+, check MSDN for MMDevice API availability), which correspond to MMDevice API, WASAPI, Core Audio API. The code itself is straightforward, with a ready to use binary to quickly lookup data of interest:

The data is detailed well and in Excel-friendly format (via Copy/Paste):

The code also automatically looks up for named Windows SDK constants, such as PKEY_Device_FriendlyName:

    Identifier    {}.{4c1a7642-3f91-43e5-8fcf-b4b1e803d3f9}
    State    DEVICE_STATE_DISABLED    0x02
        {B3F8FA53-0004-438E-9003-51A46E139BFC}, 15    16 bytes of BLOB, DA 07 03 00 02 00 09 00 0E 00 39 00 16 00 C5 02    65
        PKEY_Device_DeviceDesc    Stereo Mix    31
        {B3F8FA53-0004-438E-9003-51A46E139BFC}, 6    Realtek High Definition Audio    31
        {B3F8FA53-0004-438E-9003-51A46E139BFC}, 2    {1}.HDAUDIO\FUNC_01&VEN_10EC&DEV_0888&SUBSYS_80860034&REV_1002\4&37D44F2F&0&0201    31
        {83DA6326-97A6-4088-9453-A1923F573B29}, 3    oem29.inf:AzaliaManufacturerID.NTamd64.6.0:IntcAzAudModel:\func_01&ven_10ec&dev_0888    31
        PKEY_Device_BaseContainerId    {00000000-0000-0000-FFFF-FFFFFFFFFFFF}    72
        PKEY_Device_ContainerId    {00000000-0000-0000-FFFF-FFFFFFFFFFFF}    72
        PKEY_Device_EnumeratorName    HDAUDIO    31
        PKEY_AudioEndpoint_FormFactor    10    19
        PKEY_AudioEndpoint_JackSubType    {DFF21FE1-F70F-11D0-B917-00A0C9223196}    31
        PKEY_DeviceClass_IconPath    %windir%\system32\mmres.dll,-3018    31
        {840B8171-B0AD-410F-8581-CCCC0382CFEF}, 0    316 bytes of BLOB, 01 00 00 00 38 01 00 00 ... 00 00 00 00    65
        PKEY_AudioEndpoint_Association    {00000000-0000-0000-0000-000000000000}    31
        PKEY_AudioEndpoint_Supports_EventDriven_Mode    1    19
        {24DBB0FC-9311-4B3D-9CF0-18FF155639D4}, 3    0    11
        {24DBB0FC-9311-4B3D-9CF0-18FF155639D4}, 4    -1    11
        {9A82A7DB-3EBB-41B4-83BA-18B7311718FC}, 1    65536    19
        {233164C8-1B2C-4C7D-BC68-B671687A2567}, 1    {2}.\\?\hdaudio#func_01&ven_10ec&dev_0888&subsys_80860034&rev_1002#4&37d44f2f&0&0201#{6994ad04-93ef-11d0-a3cc-00a0c9223196}\rtstereomixwave    31
        {5A9125B7-F367-4924-ACE2-0803A4A3A471}, 0    1610612916    19
        {B3F8FA53-0004-438E-9003-51A46E139BFC}, 0    3    19
        PKEY_Device_FriendlyName    Stereo Mix (Realtek High Definition Audio)    31
        PKEY_DeviceInterface_FriendlyName    Realtek High Definition Audio    31
        PKEY_AudioEndpoint_GUID    {4C1A7642-3F91-43E5-8FCF-B4B1E803D3F9}    31

A binary [Win32, x64] and partial Visual C++ .NET 2010 source code are available from SVN.

See also:

Utility Clearance: Logical Processor Information

LogicalProcessorInformation is a fronend GUI around GetLogicalProcessorInformation API and reveals CPU configuration of the system. If you are fine tuning stuff, you might want to know what sort of CPUs are powering the applications:

  • how many?
  • fully featured cores or HyperThreading technology?
  • mutli-processor configuration and how exactly physical processors are distributed over affinity mask

API and the application gets you the data as a user-friendly dump of GetLogicalProcessorInformation output and a summary of records at the bottom:


DirectShow Filter Graph Spy: 64-bit version and hook API

Today’s update for DirectShow Filter Graph Spy introduces 64-bit version (mind the beta state) and a mini-API for an external module to be involved into graph building process.

Filter Graph Spy is offering three new interfaces that provide extensibility of the spy:

  • IFilterGraphAddRemoveHook
  • IFilterGraphConnectHook
  • IFilterGraphStateControlHook

The interfaces are contained in the type library and can be imported using #import directive. An implementation of one or more of these interfaces will receive hook style calls corresponding to respective Filter Graph Manager calls, system wide including in context of other applications.

A COM object may be registered as a hook object with Spy and NoThreadSpy COM classes under predefined registry keys:

Registering a DirectShow Filter Graph Spy Hook

Spy will instantiate the registered hook objects and forward them the calls it receive, before passing them to system Filter Graph Manager object. A hook object has an option to override default processing, including, for example, inserting its own filter in between. For example, IFilterGraph::Reconnect call is implemented the following way:

STDMETHOD(Reconnect)(IPin* pPin) throw()
    _Z4(atlTraceCOM, 4, _T("...\n"));
        OnReconnect(pT, pPin, &bDefault);
    return m_pInnerFilterGraph2->Reconnect(pPin);

Before passing the call to original Reconnect method, spy is iterating through associated hooks, passing them IFilterGraphConnectHook::OnReconnect call. Setting bDefault parameter to FALSE will prevent spy from passing the call to original method.

Included BdaHooks project shows a sample implementation of the hooking COM classes (note .rgs registration).

Filter Graph Spy is compatible with all current Windows operating systems, 32-bit and 64-bit (x64), in particular including:

  • Windows 7
  • Windows Server 2008
  • Windows Vista
  • Windows Server 2003
  • Windows XP
  • Windows 2000

NOTE: DirectShow Filter Graph Spy is NOT suitable for production environment, it is NOT licensed to be redistributed to be a part of production state software item.

Partial Visual C++ .NET 2008 source code is available from SVN, release binary included (Win32, x64); installation instructions are in another post.

RegSetKeySecurity, CRegKey::SetKeySecurity and CSecurityDesc

One thing is worth special mentioning in connection with previous post on DirectShow Filter Graph Spy on Microsoft Vista system: ATL’s CSecurityDesc class caused to waste some time.

CRegKey Key;
CSecurityDesc AdministratorsOwnerSecurityDescriptor;
ATLENSURE_SUCCEEDED(HRESULT_FROM_WIN32(Key.SetKeySecurity(OWNER_SECURITY_INFORMATION, &AdministratorsOwnerSecurityDescriptor)));

The code compiles fine, but on runtime it gives error 87 (ERROR_INVALID_PARAMETER, E_INVALIDARG) in the last line, returned from RegSetKeySecurity API call. My first guess was that ATL’s CSecurityDesc class for some reason prepared wrong descriptor which resulted in rejecting it as an argument. From the first glance it looks (not sure) that this class deals, to some extent, with structures itself rather than using API functions, so it could be that it results in something looking differently from expected by API calls.

Still the problem is in class itself and its cast from CSecurityDesc& to required SECURITY_DESCRIPTOR* type. The class only implements operator to automatically cast to const SECURITY_DESCRIPTOR* type, so the following line would not be passed by compiler:

Key.SetKeySecurity(OWNER_SECURITY_INFORMATION, AdministratorsOwnerSecurityDescriptor)

However &AdministratorsOwnerSecurityDescriptor is another level of indirection and hence SECURITY_DESCRIPTOR** type, which is passed by compiler, but results in indeed invalid argument.

So in order to correctly convert CSecurityDesc& to SECURITY_DESCRIPTOR* it can be done this way:

CRegKey Key;
CSecurityDesc AdministratorsOwnerSecurityDescriptor;

Time Zone Information & Monitor Information

I am sharing a couple of utilities to be able to quick check system settings. TimeZoneInformation prints in a human friendly style TIME_ZONE_INFORMATION structure as reported by Windows through GetTimeZoneInformation API.

.Bias: -120
.StandardName: FLE Standard Time
.StandardDate: { .wYear 0, .wMonth 10, .wDay 5, .wDayOfWeek 0, .wHour 4, .wMinute 0, .wSecond 0, .wMilliseconds 0 }
.StandardBias: 0
.DaylightName: FLE Daylight Time
.DaylightDate: { .wYear 0, .wMonth 3, .wDay 5, .wDayOfWeek 0, .wHour 3, .wMinute 0, .wSecond 0, .wMilliseconds 0 }
.DaylightBias: -60

A Visual C++ .NET 2008 source code is available from SVN, release binary included.

And the second utility is MonitorInformation to print multi-monitor related information again as reported by Windows, GetSystemMetrics and EnumDisplayMonitors APIs.

System Metrics:

Monitor 0 at (0, 0) - (1680, 1050):
  Coordinates (rcMonitor): (0, 0) - (1680, 1050)
  Work Area (rcWork): (0, 0) - (1680, 1026)
  Flags (dwFlags): 0x1
  Device Name (szDevice): \\.\DISPLAY1

A Visual C++ .NET 2008 source code is available from SVN, release binary included.