Archive for the ‘WTL’ Category:
How To: Implement DirectShow Filter using DirectX Media Object DMO (Part 5: In-Place Processing)
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)
How To: Implement DirectShow Filter using DirectX Media Object DMO (Part 4: Merit)
Previously on the topic:
- Part 1: Starting the Project
- Part 2: Video Processing
- Part 3: Persistence, Automation and Property Pages
The implemented so far filter/DMO shown a problem related to its unexpectedly high “importance” in the system with the symptom of “auto-insertion” the filter when it is not necessary. For example, let us render an AVI file through Infinite Tee Pin Filter:
The problem is that DirectShow auto-inserts our Brightness/Contrast filter into the graph while it is obviously not expected, wanted or necessary:
The problem is high filter/DMO merit value and a popular YUY2 video format the filter is advertised to accept on input during DMO registration.
How To: Implement DirectShow Filter using DirectX Media Object DMO (Part 3: Persistence, Automation and Property Pages)
Previously on the topic:
The principal task of video processing is done but there are still things mandatory for the filter to be usable. First of all, a custom interface is required to be able to control the filter from higher level application and to adjust brightness and constract correction values on the run time. Additionally, persistence would not hurt at all to be able to store correction settings along with other graph settings in GraphEdit graph file or anywhere else. Additionally, it would also be convenient to have a property page for the filter to be able to adjust the correction settings through GUI, both on graph composition and while the graph is running.
All the mentioned tasks are interconnected and ATL has an answer in implementation of:
- IDispatch-derived automation interface through IDispatchImpl class to implement custom interface to be used for external control over the filter/DMO and also to be used to access persistent properties
- IPersistStream/IPersistStreamInit interfaces through IPersistStreamInitImpl class and PROP_MAP macro map to implement persistence capabilities
- ISpecifyPropertyPages interface through ISpecifyPropertyPagesImpl class to provide custom property page
Default Struct Member Alignment surprise with Visual C++.NET 2005
I am compiling C++ project which is using IJG JPEG library using Visual Studio .NET 2005 (yes, 2008 is yet to come) and it came as a surprise that I stumbled upon struct data alignment issue. I am pretty sure this was not a problem with Visual Studio .NET 2003.
The project includes my C++ files and C source from the library. C++ code includes:
extern "C"
{
#undef FAR
#define XMD_H // Otherwise INT32 is redefined
// NOTE: See jmorecfg.h for condition compilation options
#include "cdjpeg.h"
#include "jversion.h"
};
Running this, I receive an error from the library (thanks for pointing this out early anyway!):
JPEG parameter struct mismatch: library thinks size is 360, caller expects 347.
How comes? Project settings are default and set to use default alignment /Zp. It seems as if compiler uses default value of 1 for my C++ code and uses default value of 8 for C code… with a result of break on runtime.
The workaround is in referencing C code with alignment override using #pragma pack:
extern "C"
{
#undef FAR
#define XMD_H // Otherwise INT32 is redefined
//#pragma pack(show)
#pragma pack(push, 8 )
// NOTE: See jmorecfg.h for condition compilation options
#include "cdjpeg.h"
#include "jversion.h"
#pragma pack(pop)
};
Did you know that: LVN_GETINFOTIP?
Did you know that when you handle LVN_GETINFOTIP notification message and you are provided with NMLVGETINFOTIP structure, you cannot just supply your own pszText string for the tooltip text? Instead you have to copy your string into supplied buffer, such as using _tcsncpy function. Otherwise things would not work.
BEGIN_MSG_MAP_EX(CFooPropertyPage) CHAIN_MSG_MAP(CPropertyPageT) ... MSG_LVN_GETINFOTIP(IDC_FOOLISTVIEW, OnFooListViewGetInfoTip) REFLECT_NOTIFICATIONS() END_MSG_MAP() ... LRESULT OnFooListViewGetInfoTip(NMLVGETINFOTIP* pHeader) { ATLASSERT(!pHeader->lParam); CFoo* pFoo = m_FooListView.GetItemData(pHeader->iItem); CString& sTextBuffer = m_ModelListView.GetTextBufferString(TRUE); ... sTextBuffer.TrimRight(_T("\t\n\r ")); _tcsncpy(pHeader->pszText, sTextBuffer, pHeader->cchTextMax - 1); pHeader->pszText[pHeader->cchTextMax - 1] = 0; return 0; }
Interactive RTSP Client
There has been a need in interactive RTSP (Real Time Streaming Protocol) utility to check RTSP-enabled MPEG-4 cameras - I did not find anything useful, so here goes in-house built one:
Features:
- TCP connections to RTSP servers (UDP is yet to do)
- OPTIONS and DESCRIBE buttons provide templates for RTSP messages to send to RTSP server
- Implements RFC 2617 Basic and Digest authentication (it will automatically provide Authorization header for Basic authentication with first DESCRIBE and after receiving 401 error with nonce value it will start providing Digest authentication with next DESCRIBEs
- Prints traffic data with color highlighting and ability to copy/paste
See Also:
Compiled binary of Alax.Info RTSP Client is here.
Reversing MD5 using CryptoAPI
Improving MD5 cracking application: with the use of MS Windows CryptoAPI subsystem, cracking speed increased by over 25%. I am looking forward to getting evaluation version of Intel IPP Cryptography library to compare results to obtained using CryptoAPI.
See Also: CryptAcquireContext, CryptCreateHash, CALG_MD5, CryptHashData, CCryptProv, CCryptMD5Hash.
Partial (some header files are excluded) Visual C++.NET 2005 source code can be downloaded here, compiled binary - here.
Subscribe to the comments for this post

