Published by Roman on 08 Feb 2010
This quick update for DirectShow Filter Graph Spy adds tracing for (deprecated) IAMFilterData interface, and also fixes problem with Media Player Classic – Home Cinema, when the player crashes in External Filters windows.
Partial Visual C++ .NET 2008 source code is available from SVN, release binary included (Win32, x64); installation instructions are in another post.
Published by Roman on 24 Dec 2009
DirectShow Filter Graph Spy was updated to add new functionality: spying over another DirectShow object – Filter Mapper. Filter Mapper object is used for filter registration purposes and also internally by DirectShow’s Intelligent Connect. IFilterMapper2 interface traces provide detailed description on steps DirectShow takes in order to connect and/or render filter pins. For example when trying to render MEDIATYPE_Audio pin, Filter Mapper suggested “RDP DShow Redirection Filter” and, then, “Default DirectSound Device”:
FilterMapperSpy.h(186): CFilterMapperSpy::EnumMatchingFilters: nFlags 0x0, bExactMatch 0, nMinimalMerit 0x00200001, bInputNeeded 1, nInputTypeCount 1, pInputPinCategory NULL, bRender 1, bOutputNeeded 0, nOutputTypeCount 0, pOutputPinCategory NULL FilterMapperSpy.h(191): CFilterMapperSpy::EnumMatchingFilters: nInputTypeIndex 0, MajorType {73647561-0000-0010-8000-00AA00389B71}, Subtype {00000000-0000-0000-0000-000000000000} FilterMapperSpy.h(212): CFilterMapperSpy::EnumMatchingFilters: pMoniker @device:sw:{083863F1-70DE-11D0-BD40-00A0C911CE86}\{AB9D6472-752F-43F6-B29E-61207BDA8E06} FilterMapperSpy.h(220): CFilterMapperSpy::EnumMatchingFilters: sFriendlyName "RDP DShow Redirection Filter", sDescription "", sDevicePath "" FilterMapperSpy.h(212): CFilterMapperSpy::EnumMatchingFilters: pMoniker @device:cm:{E0F158E1-CB04-11D0-BD4E-00A0C911CE86}\Default DirectSound Device FilterMapperSpy.h(220): CFilterMapperSpy::EnumMatchingFilters: sFriendlyName "Default DirectSound Device", sDescription "", sDevicePath ""
Important is that DirectShow’s internals are using the mapper through COM instantiation and this provides a safe method to override default behavior process wide in order to, for example, extend Intelligent Connect functionality onto custom, unregistered globally, private filters.
Also, the binary is renamed from FilterGraphSpy.dll to DirectShowSpy.dll.
Partial Visual C++ .NET 2008 source code is available from SVN, release binary included (Win32, x64); installation instructions are in another post.
Published by Roman on 01 Nov 2009
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:
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:
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")); HOOK_PROLOG(CFilterGraphConnectHookHost) OnReconnect(pT, pPin, &bDefault); HOOK_EPILOG() 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:
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.
Published by Roman on 06 Oct 2009
Having hard time to connect to remote filter graph on Windows 7 machine, I suspected that some of the filters do not like being connected through marshaling and freeze. Or, actually more likely, it is SDK’s proppage.dll which hosts proxy stub pairs behaves itself in a not quite expected way and freezes remote application (Graph Edit or similar) during attempt to connect to remote graph.
As the goal was to find out details about connection media types between the filters being spied over, the spy received a new feature of logging graph details each time the graph is going to running state:
Filter 7: Name "[1BDADev]", Class {17CCA71B-ECD7-11D0-B908-00A0C9223196}, State 2
Pin 1: Name "MPEG2 Transport", Direction "Input", Peer "[0BDATnr].MPEG2 Transport"
Connection media type:
majortype {E436EB83-524F-11CE-9F53-0020AF0BA770}, subtype {E06D8023-DB46-11CF-B4D1-00805F6CBBEA}, pUnk 0x00000000
bFixedSizeSamples 0, bTemporalCompression 0, lSampleSize 1
formattype {8DEDA6FD-AC5F-4334-8ECF-A4BA8FA7D0F0}, cbFormat 24, pbFormat 0x00350868
[0x0000] BC 00 00 00 38 9A 00 00 00 00 00 00 00 00 00 00
[0x0010] 00 00 00 00 00 00 00 00
Pin 2: Name "MPEG2 Transport", Direction "Output", Peer "Infinite Pin Tee Filter[BDATsIft].Input"
Connection media type:
majortype {E436EB83-524F-11CE-9F53-0020AF0BA770}, subtype {F4AEB342-0329-4FDD-A8FD-4AFF4926C978}, pUnk 0x00000000
bFixedSizeSamples 1, bTemporalCompression 0, lSampleSize 39480
formattype {0F6417D6-C318-11D0-A43F-00A0C9223196}, cbFormat 0, pbFormat 0x00000000
Filter 8: Name "[0BDATnr]", Class {17CCA71B-ECD7-11D0-B908-00A0C9223196}, State 2
Pin 1: Name "Input0", Direction "Input", Peer "Microsoft Network Provider[NwPvd].Antenna Out"
Connection media type:
majortype {71985F41-1CA1-11D3-9CC8-00C04F7971E0}, subtype {E436EB8E-524F-11CE-9F53-0020AF0BA770}, pUnk 0x00000000
bFixedSizeSamples 0, bTemporalCompression 0, lSampleSize 1
formattype {0F6417D6-C318-11D0-A43F-00A0C9223196}, cbFormat 0, pbFormat 0x00000000
Pin 2: Name "MPEG2 Transport", Direction "Output", Peer "[1BDADev].MPEG2 Transport"
Connection media type:
majortype {E436EB83-524F-11CE-9F53-0020AF0BA770}, subtype {E06D8023-DB46-11CF-B4D1-00805F6CBBEA}, pUnk 0x00000000
bFixedSizeSamples 0, bTemporalCompression 0, lSampleSize 1
formattype {8DEDA6FD-AC5F-4334-8ECF-A4BA8FA7D0F0}, cbFormat 24, pbFormat 0x00350868
[0x0000] BC 00 00 00 38 9A 00 00 00 00 00 00 00 00 00 00
[0x0010] 00 00 00 00 00 00 00 00
Partial Visual C++ .NET 2008 source code is available from SVN, release binary included; installation instructions are in another post.
Published by Roman on 30 Sep 2009
From a conversation:
Q: I am using Web camera with DirectShow. Camera has only capture pin, so I am looking for the best way to switch resolution on the pin while graph is running. I would like to keep preview with smaller image size and when i would like to capture an image i would like to switch to full resolution. I have to use sample grabber callback since i need access to single image to process them. Is there a way to do that without stopping and starting a graph? This works but very slow between captures.
Is it possible to just reconnect the sample grabber only with new media changes and then resume the graph? Currently i just kill the graph and start it again, but it takes few seconds to do so, so I am looking the way to reduce that time.
There is no way to switch resolution on the running graph. There is a technique to dynamically start/stop individual filters and re-negotiate resolutions (media types), but it does not work for the majority of filters. Additionally to that Sample Grabber Filter cannot change resolution too, as it passes data through.
If you only have to use switched resolution for preview, you can use Geraint’s GMFBridge Toolkit to join two graphs, and a filter that changes resolution. Combining all that you will have a running capture graph that [also] renders video to a bridge sink. In the other graph you have another bridge sink that receives video from first graph and then you resize video to the resolution of interest already in the second graph. You can stop and reconfigure only second graph to update resolution and have first graph running and capturing. This is the best you can do, or just stop your single graph and change resolution this simple way.
So a solution, which is used by many, and I can recommend it too, is to use GMFBridge bridging. Additionally, you can find questions and answers on it on MSDN DirectShow Development Forum (search for “bridge” there). With a certain effort you can duplicate this with your own code but this is more or less ready to use solution and, again, the key advantage you have that you have two graphs which you can top independently.
Would it be possible to use smart tee as a splitter on the capture pin, and then use two sample grabbers on capture and preview, one with smaller resolution and the other one with higher one?
With a Smart Tee Filter you will still have 1 graph, so no individual resolution changes without stopping the graph. Additionally to that, Smart Tee Filter will deliver same frame on its output pins, so they will have to have one resolution and no resizing takes place inside.
Also, is it possible to run 2 graphs in the same time? Same device, 2 graphs, 2 sample grabbers.
Most likely no, for only one reason: you won’t be able to have two running filters for the same device, as source filter will exclusively lock the device. So capture filter will be a single filter. You can use Infinite Tee Pin Filter to split stream between 2+ processing lines. And you can use the same bridge to pass data into another graph for further processing.
Published by Roman on 18 Sep 2009
Unlike video, audio is difficult to troubleshoot in a way that once an issue has been noticed it was dynamic and already in past and it may be difficult to repeat, explain, forward as a screenshot etc. So it needs a visualization in order to check certain specific of the media stream.
Here we go with a Audio Oscillogram Filter, a filter which may be inserted into audio part of the graph, it insists on PCM audio (multichannel is OK, 8 or 16 bits per sample), so decoders might be required upstream and will be automatically inserted.
Once the filter is running, it shows a tool window with a visualization of the waveform coming through. Additionally, it shows a discontinuity sample (that is, a sample with AM_SAMPLE_DATADISCONTINUITY flag) with a thick read vertical line, and a mismatch (gap or override) in neighboring sample start and stop times with a thin red line.
Additionally to this, a window provides an option to pop up downstream audio renderer property sheet in order to check/debug rendering statistics, such as buffer fullness and break count (programmatically available via IAMAudioRendererStats interface). Unfortunately Microsoft does not provide a well done proxy/stub pair for this interface and the property page and there is no way to access this property page connecting to graph remotely. Using this filter the property sheet is shown directly from the hosting process and works correctly.
A partial Visual C++ .NET 2008 source code is available from SVN, release binary included.
Utility.dll (download) hosts the following classes:
The filter visualizes PCM audio data going through in a form of oscillogram.
The filter will create a tool window with audio visualization when put into paused/running state. The filter graph should be controlled (IMediaControl) from a GUI aware apartment so that window messages could reach internal filter’s window.
Published by Roman on 05 Aug 2009
One of the DirectShow’s most important features is Intelligent Connect, which allows Filter Graph Manager to build graphs out of independent filters trying to connect them together including options to fall back to originally non-preferred alternatives and so on.
It is however important that filters are properly registered with the Filter Mapper. For the developers to do so, there are special guidelines for registering filters. Unfortunately it is not always the case that developers carefully take them into consideration, and so we have compatibility issues. In particular a faulty filter may break an application it is not intended to be used in in first place. Some examples were already mentioned: Ahead Nero NeResize Filter, FFDShow Video Decoder Filter, PICVideo MJPEG Decompressor Filter.
As we are moving on, the brilliant collection is expanding. New entry on the list:
MainConcept Color Space Converter Filter
Friendly Name: MainConcept Color Space Converter
File Name: mccsc.ax
File Version: 1.0.103.60203 (note that other versions might be hopefully free from this problem)
Merit: 0×00600000 (MERIT_NORMAL)
Symptoms: registers itself under higher merit and takes over standard Color Space Converter Filter. As such, might be used in various applications including those, where it is not supposed to appear. Does not fully implement functionality of the filter being replaced and can crash breaking expected operation of third party application.
