This adds a small update to the recently published GPS Location/Coordinate Converter utility:

• Seconds in Degrees, Minutes & Seconds notation are shown and are accepted as floating point numbers
• More shortcuts to popular online map services (note that only Google Maps and Yandex Maps are still accepted as input via clipboard):
• Bing Maps
• Yahoo Maps
• Open Street Map
• WikiMapia

The latter makes the tool an easy to use converted between the services for a GPS POI.

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

The minimalistic sample demonstrates support of [deprecated] Waveform Audio API for multiple playback streams.

Depending on command line parameters, the application starts threads to open audio hardware using separate waveOutOpen call and stream one or more generated sine waves:

• 1,000 Hz sine wave as 22,050 Hz, Mono, 16-bit PCM (command line parameter “a”)
• 5,000 Hz sine wave as 32,000 Hz, Mono, 16-bit PCM (command line parameter “b”)
• 15,000 Hz sine wave as 44,100 Hz, Mono, 16-bit PCM (command line parameter “c”)

Check(waveOutOpen(&hWaveOut, WAVE_MAPPER, &WaveFormatEx, NULL, NULL, CALLBACK_NULL));
ATLASSERT(hWaveOut);
WAVEHDR* pWaveHeader;
HGLOBAL hWaveHeader = (WAVEHDR*) GlobalAlloc(GMEM_MOVEABLE | GMEM_SHARE, sizeof *pWaveHeader + WaveFormatEx.nAvgBytesPerSec * 10);
pWaveHeader = (WAVEHDR*) GlobalLock(hWaveHeader);
ATLENSURE_THROW(pWaveHeader, E_OUTOFMEMORY);
pWaveHeader->lpData = (LPSTR) (BYTE*) (pWaveHeader + 1);
pWaveHeader->dwBufferLength = WaveFormatEx.nAvgBytesPerSec * 10;
//pWaveHeader->dwUser = 
pWaveHeader->dwFlags = 0;
pWaveHeader->dwLoops = 0;
#pragma region Generate Actual Data
{
    SHORT* pnData = (SHORT*) pWaveHeader->lpData;
    SIZE_T nDataCount = pWaveHeader->dwBufferLength / sizeof *pnData;
    for(SIZE_T nIndex = 0; nIndex < nDataCount; nIndex++)
    pnData[nIndex] = (SHORT) (32000 * sin(1.0 * nIndex / WaveFormatEx.nSamplesPerSec * nFrequency * 2 * M_PI));
}
#pragma endregion 
Check(waveOutPrepareHeader(hWaveOut, pWaveHeader, sizeof *pWaveHeader));
Check(waveOutWrite(hWaveOut, pWaveHeader, sizeof *pWaveHeader));
GlobalUnlock(hWaveHeader);

The operating system is supposed to mix the waves, which can be easily perceived taking place. It is possible to run the application with multiple waveforms within a process, e.g. “abc” command line parameter, and/or start multiple instances of the application.

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

Crime

An application which builds a DirectShow graph unexpectedly started failing with VFW_E_NOT_CONNECTED (0×80040209) error code.

Scene

The problem takes place during DirectShow graph building, yet in stopped state. Specific call which appeared to be giving out the error in first place appears to be EVR input pin’s IPin::ConnectionMediaType, and the problem is also specific to Enhanced video Renderer (Windows 7, but not necessarily only this version).

Investigation

The problem does not appear to be persistent. On the contrary, it is taking place for just a few milliseconds after pin connection. After the problem is gone, it does not seem to ever come up again unless the filter graph is built again from the beginning.

EVR pin connection is always reporting success, so the following error code stating VFW_E_NOT_CONNECTED “The operation cannot be performed because the pins are not connected.” goes against documented behavior, and is thus a bug.

Depending on time between pin connection and media type polling, the call can reach EVR:

• before it starts showing the problem – stage A
• at the time the call fails – stage B
• after the failure time interval, when the call is successful from then on – stage C

Thus, the problem is limited to specific use cases:

• the application should care about media type on EVR input
• unexpected failure takes place when the call reaches in stage B
• also found: the clipping window for the EVR has to belong to a non-primary monitor

If an application keep polling for media type in a loop, the result may be about the following:

UINT nStageA = 0, nStageB = 0, nStageC = 0;
// [...]
for(; ; )
{
    AM_MEDIA_TYPE MediaType;
    ZeroMemory(&MediaType, sizeof MediaType);
    const HRESULT nConnectionMediaTypeResult = pInputPin->ConnectionMediaType(&MediaType);
    if(SUCCEEDED(nConnectionMediaTypeResult))
    {
        if(nStageB)
        {
            nStageC++;
            break;
        } else
            nStageA++;
    } else
    {
        ATLASSERT(nConnectionMediaTypeResult == VFW_E_NOT_CONNECTED);
        nStageB++;
    }
    CoTaskMemFree(MediaType.pbFormat);
}
// [...]
CString sMessage;
sMessage.Format(_T("Bingo!\r\n\r\n") _T("nStageA %d, nStageB %d - 0x%08x, nStageC %d\n"), nStageA, nStageB, nResult, nStageC);
AtlMessageBox(m_hWnd, (LPCTSTR) sMessage, _T("Result"), MB_ICONERROR);

Workaround

An obvious straightforward workaround is to follow EVR connection with a wait for Stage B to pass, or timeout – whichever takes place first.

Also, vote for the bug on Microsoft Connect.

More Details

Video renderer filter are notorious for re-agreeing media type and being fretful as for memory allocators and media types (for a good reason though!). So it makes sense to suggest that the problem takes place when the filter is doing something related, such as it starts background activity immediately after connection in order to discover upstream peer capabilities.

In order to possibly get details on this, it is possible to raise an exception as soon as Stage B is detected and take a look at thread states using a debugger. Indeed, on of the background threads is engaged in EVR reconnection activity:

Yes it does the reconnection, but nevertheless it is expected to do the things undercover and transparently, it still allows a failure on the outer API.

     evr.dll!GetSourceRectFromMediaType() + 0x37 bytes    
     evr.dll!CEVRInputPin::CheckMediaType() + 0x81 bytes    
     evr.dll!CBasePin::ReceiveConnection() + 0x61 bytes    
     evr.dll!CEVRInputPin::ReceiveConnection() + 0x1fc2d bytes    
     quartz.dll!CBasePin::AttemptConnection() - 0x21 bytes    
     quartz.dll!CBasePin::TryMediaTypes() + 0x60 bytes    
     quartz.dll!CBasePin::AgreeMediaType() + 0x54 bytes    
     quartz.dll!CBasePin::Connect() + 0x46 bytes    
     quartz.dll!CFilterGraph::ConnectDirectInternal() + 0x83 bytes    
     quartz.dll!CFilterGraph::ConnectRecursively() + 0x2c bytes    
     quartz.dll!CFilterGraph::ConnectInternal() + 0xde bytes    
     quartz.dll!CFilterGraph::Connect() + 0x17 bytes    
     quartz.dll!CFGControl::WorkerDisplayChanged() + 0xf1 bytes    
     quartz.dll!CFGControl::CGraphWindow::OnReceiveMessage() + 0x2e2a bytes    
>    quartz.dll!WndProc() + 0x3e bytes    
     user32.dll!_InternalCallWinProc@20() + 0x23 bytes    
     user32.dll!_UserCallWinProcCheckWow@32() + 0xb7 bytes    
     user32.dll!_DispatchMessageWorker@8() + 0xed bytes    
     user32.dll!_DispatchMessageW@4() + 0xf bytes    
     quartz.dll!ObjectThread() + 0x65 bytes

A test Visual C++ .NET 2010 application is available from SVN. The code requires a media file, and refers to 352×288 I420.avi, which is included into ZIP file attached to MS Connect Feedback.

This does not update the software with new features, but there are a few simple things worth mentioning explicitly.

The first is that virtual DirectShow camera device can be set up with both M-JPEG and JPEG URLs. That is, IP cameras which do not implement M-JPEG, or implement it in a buggy way (there is a *huge* deal of such out there) can still be set up to send video as individual video frames/images as long as they implement JPEG snapshots. This is taking place often at a lower frame rate, but still works.

The driver will automatically detect type of URL (by response from the device) and will choose best access method for the given URL.

Second is that if you are looking for IP Video Source software version, such as to check against available updates, it is here on the UI (right click the caption):

The IP Video Source update provides several improvements to the driver:

• copy/paste feature to backup, restore, or synchronize installed devices between 32-bit and 64-bit versions
• 64-bit version and .MSI
• dynamic video resizing (via Video Resizer DSP)
• Adobe FMLE compatibility

Updates in greater detail follow.

Device Copy/Paste Feature

The video device management window is providing Copy and Paste buttons, which let user transfer device information, including name and settings, through clipboard for various purposes:

• save data in order to be able to restore devices later
• restore devices from saved list, or re-create from a list saved on another machine
• duplicate a device
• synchronize devices between 32-bit and 64-bit versions

The device data is a text, one line per device, lines in comma-separated values (CSV) format.

64-Bit Version

Software is available in both 32-bit and 64-bit versions. While most of multimedia software is still 32-bit, sometimes 64-bit version is really helpful to, for example:

• interface to “Any CPU” .NET code which executes in 64-bit on a 64-bit operating system
• go beyond 32-bit code boundaries, especially in part of multiple devices and virtual address space limit

64-bit version duplicates functionality available in 32-bit version, though 32- and 64-bit modules run in completely separated environments.

Dynamic Video Resizing

The source DirectShow filter is capable of connecting with media types different from original/camera media type in resolution part for decompressed video. The filter is internally taking advantage of Video Resizer DSP, and resizes decompressed video to format of interest.

As Video Resizer DSP is available starting with Windows Vista, the functionality availability is subject to the same conditions.

The feature is absolutely required for Adobe Flash Media Live Encoder software, as it make certain assumptions as for supported resolutions, and completely ignores the information the filter makes available in standard way.

Adobe Flash Media Live Encoder Friendliness

The update make the device much closer to interoperation with Adobe product. The software works around a handful of bugs, including as ridiculous as neglecting to provide correct BI_RGB value in BITMAPINFOHEADER::biCompression structure, yet researchers are still to resolve the remained ones.

FMLE would start perfect and stream video being run under debugger, otherwise in a regular run chances are that Adobe application would internally respond with E_UNEXPECTED failure for unknown reason, stop any encoding without giving a single little notice on the GUI.

After all, the encoding runs perfectly through web based encoder, and the driver is providing a good way to stream to video distribution sites such as http://ustream.tv, http://livestream.com from an IP camera or video encoder.

Download Information

• Download (32-bit): AlaxInfoIpVideoSourceSetup.msi
• Download (64-bit): AlaxInfoIpVideoSourceSetup-x64.msi
• License: This software is free to use

This implements a DirectShow driver/wrapper over a HTTP based JPEG/M-JPEG streamed video, widely available with IP cameras. Once installed, it provides a Start Menu shortcut to manage video capture devices, where a user can add/remove devices. The devices are automatically registered with DriectShow and are available to applications.

The compatibility list includes:

• Windows SDK AmCap Sample (reference)
• VideoLan VLC
• Skype (see below)
• Google Talk Video Chat
• Luxriot (as rather an example as Luxriot has its own generic JPEG/M-JPEG device driver, however this still demonstrates compatibility and interoperability of applications)
• GraphEdit, GraphStudio and similar tools

For a created device it is required to configure:

1. JPEG or M-JPEG resource URL on the device, where the driver will access video feed or sequential snapshots
2. Image/video size on the device

Resource URLs vary from device to device and there is no standard identifier. This has to be looked up for specific model in device API reference or SDK. For JPEG snapshots it is possible to copy image shortcut from web browser and paste address into device settings.

Note that some devices, especially low end IP cameras deliver non-compliant feed which can be decoded either by manufacturer’s ActiveX control or model-specific implementation which this driver does not convert and is unlikely to ever cover. The driver will only work with hardware which honors industry standards.

For example, Stardot NetCam SC cameras make the video feed accessible using /nph-mjpeg.cgi resource, so the full URL will consist of protocol prefix “http://”, optional username and password (see screenshot above), IP address or host name e.g. “demo2.stardotcams.com”, resource identifier on the device “/nph-mjpeg.cgi”.

Hence, http://demo2.stardotcams.com/nph-mjpeg.cgi

It is necessary to provide video size of the footage in advance so that the driver could negotiate content media types without accessing the device. Future versions of the driver might implement auto-detection.

Skype Compatibility

To make the device work with Skype, it is necessary to:

1. Configure the device (using its web interface) to work at resolution 640×480
2. Add/configure device with Alax.Info IP video Source as described above, including setting of 640 by 480 pixel resolution in device configuration

Internals

Software implements and registers video input/capture devices, listed under DirectShow CLSID_VideoInputDeviceCategory category. The applications access devices from the list and treat as a regular device such as web camera.

Windows SDK AmCap sample will create the following DirectShow graph where the source filter implemented by this software:

Internally, software creates a worker filter graph in order to stream data from the device:

To decode video, software uses stock MJPEG Decompressor Filter provided with operating system.

Download Information

• Download (32-bit): AlaxInfoIpVideoSourceSetup.msi
• Download (64-bit): AlaxInfoIpVideoSourceSetup.msi-x64
• License: This software is free to use

EnumerateVcmCodecs uses ICOpen API to enuerate available codecs and prints out information obtained from enumeration. 32-bit and 64-bit versions respectively enumerate codecs available for the platform (lists may vary because the codecs are actually provided by different DLLs, built for respective platform).

szName
  fccType: 0x63646976 (vidc), fccHandler 0x64697663 (cvid)
  dwFlags 0
  dwVersion 0x0, dwVersionICM 0x104
  szDescription ""
  szDriver "iccvid.dll"
szName
  fccType: 0x63646976 (vidc), fccHandler 0x30323469 (i420)
  dwFlags 0
  dwVersion 0x0, dwVersionICM 0x104
  szDescription ""
  szDriver "msh263.drv"
...

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

See also:

• related topic on MSDN Forums

RasterizeFont utility takes a font on the input (such as Windows .TTF – True-Type Font) and paints individual characters into bitmaps. Utility output includes separate bitmap (.BMP) files for requested characters and C++ source code of the bimap arrays (this was included into microcontroller project).

A configuration .INI file defines rasterizer parameters:

[General]
Width=48
Height=72
Horizontal Adjustment=1
Vertical Adjustment=0
Outline=1

[Font]
Face=Times New Roman
Height=48
Weight=1024

[Bitmaps]
PathTemplate=Character-%04x.bmp

And a list of characters of interest is passed as a command line argument.

const BYTE pnCharacter007a[] = // 0x007a z
{
    0x55, 0x55, 0x55,  // 01 01 01 01 01 01 01 01 01 01 01 01 
    0x55, 0x55, 0x55,  // 01 01 01 01 01 01 01 01 01 01 01 01 
    0x55, 0x55, 0x55,  // 01 01 01 01 01 01 01 01 01 01 01 01 
    0x54, 0x00, 0x05,  // 01 01 01 00 00 00 00 00 00 00 01 01 
    0x52, 0xaa, 0xa1,  // 01 01 00 10 10 10 10 10 10 10 00 01 
    0x52, 0x00, 0xa1,  // 01 01 00 10 00 00 00 00 10 10 00 01 
    0x54, 0x42, 0x85,  // 01 01 01 00 01 00 00 10 10 00 01 01 
    0x55, 0x2a, 0x15,  // 01 01 01 01 00 10 10 10 00 01 01 01 
    0x54, 0xa0, 0x45,  // 01 01 01 00 10 10 00 00 01 00 01 01 
    0x52, 0x80, 0x21,  // 01 01 00 10 10 00 00 00 00 10 00 01 
    0x52, 0xaa, 0xa1,  // 01 01 00 10 10 10 10 10 10 10 00 01 
    0x54, 0x00, 0x05,  // 01 01 01 00 00 00 00 00 00 00 01 01 
    0x55, 0x55, 0x55,  // 01 01 01 01 01 01 01 01 01 01 01 01 
    0x55, 0x55, 0x55,  // 01 01 01 01 01 01 01 01 01 01 01 01 
};

A binary [Win32] and Visual C++ .NET 2008 source code are available from SVN.

ExportAviResources walks through AVI video clips attached as resources to a binary file and exports them into separate files.

Such clips can be used with Animation Controls for GUI animations. You might want to run the utility against SYSTEM32/SYSWOW64 folders to see if any of stock animations are good for you:

D:\>for %i in (C:\Windows\system32\*.dll) do "..\Utilities\ExportAviResources\x64\Release\ExportAviResources.exe" "%i"

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

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:

Logical Processors:

Mask: 0x00000003
Relationship: RelationProcessorCore (0x0)
ProcessorCore.Flags: 0x01

Mask: 0x00000003
Relationship: RelationCache (0x2)
Cache.Level: 1
Cache.Associativity: 8
Cache.LineSize: 64 (0x40)
Cache.Size: 32768 (0x8000)
Cache.Type: CacheData (0x2)

Mask: 0x00000003
Relationship: RelationCache (0x2)
Cache.Level: 1
Cache.Associativity: 4
Cache.LineSize: 64 (0x40)
Cache.Size: 32768 (0x8000)
Cache.Type: CacheInstruction (0x1)

Mask: 0x00000003
Relationship: RelationCache (0x2)
Cache.Level: 2
Cache.Associativity: 8
Cache.LineSize: 64 (0x40)
Cache.Size: 262144 (0x40000)
Cache.Type: CacheUnified (0x0)

Mask: 0x0000000c
Relationship: RelationProcessorCore (0x0)
ProcessorCore.Flags: 0x01

...

Mask: 0x000000ff
Relationship: RelationProcessorPackage (0x3)

...

Mask: 0x000000ff
Relationship: RelationNumaNode (0x1)
NumaNode.NodeNumber: 0x0

Record Count per Relationship:
 RelationProcessorCore (0x0): 4
 RelationNumaNode (0x1): 1
 RelationCache (0x2): 13
 RelationProcessorPackage (0x3): 1
 RelationGroup (0x4): 0

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