Previously on the topic:
- Part 1: Starting the Project
- Part 2: Video Processing
- Part 3: Persistence, Automation and Property Pages
- Part 4: Merit
Due to the nature of the brightness and constract correction processing, it would make sense to combine and simplify processing to apply correction “in-place”, that is without copying data from input to output buffer, but instead processing the same buffer before it is passed further downstream.
DMO API offers additional optional IMediaObjectInPlace interface to be implemented on the DMO which the hosting object might prefer to regular IMediaObject.
The interface itself is simple with basically the only Process method to actually handle the processing:
// IMediaObjectInPlace STDMETHOD(Process)(ULONG nSize, BYTE* pnData, REFERENCE_TIME nStartTime, DWORD nFlags) STDMETHOD(Clone)(IMediaObjectInPlace** ppMediaObject) STDMETHOD(GetLatency)(REFERENCE_TIME* pnLatencyTime)
Still the interest in in-place processing in DMO is more abstract because current DMO Wrapper Filter implementation does not take advantage of in-place processing and chooses to always work through IMediaObject.
However if the object is hosted directly, in-place processing might make sense and be important.
To support in-place processing in the DMO it is required to inherit from interface and add it to the COM map:
class ATL_NO_VTABLE CBrightnessContrastObject : public CComObjectRootEx<CComMultiThreadModel>, ... public IMediaObjectInPlace ... BEGIN_COM_MAP(CBrightnessContrastObject) ... COM_INTERFACE_ENTRY(IMediaObjectInPlace) END_COM_MAP()
And implement the IMediaObjectInPlace methods, of which IMediaObjectInPlace::Process is the essential.
Source code: DmoBrightnessContrastSample.05.zip (note that Release build binary is included)
4 Replies to “How To: Implement DirectShow Filter using DirectX Media Object DMO (Part 5: In-Place Processing)”
- You are using wrong debugger engine, you need to use “Native” debugger. It may be set to “Auto” and it’s loading a different one, e.g. managed
- It shows a warning because it does not have symbols for GraphEdt.exe, but as soon as the process loads your DLL it will be able to stop at breakpoints
- You’re building your DLL without debug information, esp. in Release configuration, and the debugger just does not have information about where to pub the breakpoint in the right place
- You’re confusing somewhere 32 and 64-bit versions of binaries, e.g. you build 64-bit and start 32-bit GraphEdit
It appeared in Visual Studio 2008, just comment it out.
Yes, it is an undocumented [yet] feature but generated by default project wizard.
I am pretty sure Microsoft will document it soon and it will be quite useful: it will allow registration of COM classes from under non-admin account. However it might be still not useful enough for DMOs because they will need additional entries under HKEY_CLASSES_ROOT for which there will still be insufficient permissions.
See also: ATL and Visual Studio C++.NET 2008 Goodies
You’re doing it the right way. Start GraphEdit and make it load your DLL. The possible problems on this way are:
There is nothing wrong in your description, it is how it is going to work. You build your own DLL but you start GraphEdit, a different application, right? At this point why would your source contain a single line you can break at? No, it does not.
It’s only when you insert your filter in the GraphEdit instance, it would load your DLL and debugger will see this and enable all breakpoints. This is where it starts working from. If it does not, make sure it opens right DLL. For example, you should be unable to rename or delete the DLL file at this time as it should be in use by GraphEdit.
See also in TMH’s FAQ: Can I debug my filter in GraphEdit or another application?
When you register filter, some information is written into system registry. Then applications like GraphEdit read this information without instantiating a filter.
Blog reader question:
You should regsvr32 using administrator privileges – you already found it out.
32 and 64 bit versions run independently. You should build both, regsvr32 both and then they will both be available to 32/64 bit GraphEdit and applications.
32-bit apps will see 32-bit DMO registration and will use it regardless of 64-bit version registration/availability and vice versa.