{"id":893,"date":"2009-04-01T09:48:45","date_gmt":"2009-04-01T07:48:45","guid":{"rendered":"https:\/\/alax.info\/blog\/?p=893"},"modified":"2009-04-01T15:21:24","modified_gmt":"2009-04-01T13:21:24","slug":"yv12-extended-video-renderer-strides-private-dmo-and-more","status":"publish","type":"post","link":"https:\/\/alax.info\/blog\/893","title":{"rendered":"YV12, Extended Video Renderer Strides, Private DMO and more"},"content":{"rendered":"

Recently it was the time to sort out an issue with a video DMO<\/a>, which outputs YV12<\/a> video and in the same time is capable of supporting extended video strides<\/a> in order to efficiently make a direct connection to Video Mixing Renderer Filters<\/a>.<\/p>\n

From past experience, I already knew that some bugs are definitely involved but their effect was yet unexplored. For a testbed application, I took good old FrameRateSample02<\/a> application, which generates multiple video feeds and routes it to video renderers:<\/p>\n

\"FrameRateSample02<\/a><\/p>\n

With new source video choices the application is capable of constructing filter graphs that use a private DMO (that is hosted inside the executable) wrapped with DMO Wrapper Filter<\/a>, with a graph topology shown below:<\/p>\n

\"Filter<\/a><\/p>\n

The DMO does not do any processing, except support for extended strides while copying original data into buffer streamed to video renderer. Extended strides for a planar YUV format is a bit tricky. Are they supported at all? Yes, they are and video renderer might still request an extended stride and in which case origial MxN video needs to be copied into (M+P)xN buffer. Unlike packed pixel format, unused space is distributed in a bit different way but still very much similarly: output buffer is still a regular (M+P)xN rectangle, where the effective picture of size MxN should be copied into top left corner.<\/p>\n

The problem I was aware of from past experience showed up immediately once the filters connected. After a dynamic format change initiated by the VMR, the filters report different connection media types. DMO Wrapper Filter<\/a> still shows original connection time connection media type, while Video Mixing Renderer Filter<\/a> shows media type it switched to.<\/p>\n

\"Media<\/a><\/p>\n

This looks like DMO Wrapper Filter<\/a> bug, but was yet to check if it still handles the new media type properly and passes the format change to the underlying DMO object. Taking into consideration the extent DMOs are used by Microsoft<\/a>, it had to, thought I never met this in the MSDN<\/a> documentation.<\/p>\n

Further debugging revealed that DMO Wrapper Filter<\/a> does handle the media type change and forward it to the DMO through IMediaObject::SetOutputType<\/a> method. This happens when DMO already received its first input, and immediately before following IMediaObject::ProcessOutput<\/a> method call:<\/p>\n

rodmo.h(293) : CMediaObjectT<class CVideoDmo>::AllocateStreamingResources: ...\r\nrodshow.h(2716) : CBaseFilterT<class CMainDialog::CSourceFilter>::Pause: ...\r\nrodshow.h(2722) : CBaseFilterT<class CMainDialog::CSourceFilter>::Pause: m_State 0\r\nrodshow.h(2730) : CBaseFilterT<class CMainDialog::CSourceFilter>::Pause: m_State 1\r\nrodshow.h(2784) : CBaseFilterT<class CMainDialog::CSourceFilter>::GetState: nTimeout 0\r\nrodmo.h(679) : CSimpleMediaObjectT<class CVideoDmo,1>::GetInputStatus: nInputStreamIndex 0\r\nrodmo.h(702) : CSimpleMediaObjectT<class CVideoDmo,1>::ProcessInput: nInputStreamIndex 0, nFlags 0x1\r\nrodmo.h(527) : CSimpleMediaObjectT<class CVideoDmo,1>::SetOutputType: nOutputStreamIndex 0, nFlags 0x0<\/strong>\r\n<\/span>rodmo.h(727) : CSimpleMediaObjectT<class CVideoDmo,1>::ProcessOutput: nFlags 0x1, nOutputBufferCount 1<\/pre>\n
So, the media type change is handled and the problem is only limited to reporting wrong (original) media type off the wrapper filter output pin.<\/p>\n
Investigation of filter connection however brought up another interesting fact, memory allocator properties:<\/p>\n
\"Memory<\/a><\/p>\n
As the filters switched to a new media type, with extended strides, the memory allocator should obviously have been updated accordingly, in order to support larger buffer. However current memory allocator properties<\/a> indicate old buffer size of 460,800 bytes, while new media type assumes 737,280 buffer size at the very least. The samples are however streamed fine, so the issue is also limited to incorrectly reported size.<\/p>\n
This memory allocator is managed by the Video Mixing Renderer Filter<\/a>, so the problem seems to be relating to it.<\/p>\n
Good news however was that video was streamed and displayed correctly.<\/p>\n
One thing that deserves special attention is making a DMO private. I already wrote another post on private DMOs<\/a> some time ago, and this time the sample shows even a better way in case one does not need the DMO available for Intelligent Connect<\/a> (in which case DMORegister<\/a> call along with administrative privileges will be required),\u00a0 just for a private instantiation. DMO is typically created by CoCreateInstance<\/a> from inside the DMO Wrapper Filter<\/a>, e.g. using IDMOWrapperFilter::Init<\/a> method, so it is necessary to either register COM class, or… just register its class object for the process using CoRegisterClassObject<\/a>.<\/p>\n
There is no need for direct usage of API since ATL already wrapped the calls and we are to take advantage of what is already available. First of all, the DMO class requires certain CLSID, because we don’t have one typically declared in IDL. A good place for attaching CLSID is class declaration and __declspec keyword<\/a>:<\/p>\n
class<\/span> __declspec<\/span>(<\/span>uuid(<\/span>\"<\/span>88B976BE-EEE6-45b1-A21B-42A941DF8819<\/span>\"<\/span>)<\/span>)<\/span> ATL_NO_VTABLE CVideoDmo :<\/span>\r\n    public<\/span> CComObjectRootEx<<\/span>CComMultiThreadModelNoCS><\/span>,<\/span>\r\n    public<\/span> CComCoClass<<\/span>CVideoDmo><\/span>,<\/span>\r\n    public<\/span> CSimpleMediaObjectT<<\/span>CVideoDmo,<\/span> 1<\/span>><\/span>\r\n{<\/span><\/pre>\n
Further a COM class is typically referenced into module’s object map byan OBJECT_ENTRY_AUTO<\/a> macro:<\/p>\n
\/\/<\/span>OBJECT_ENTRY_AUTO(__uuidof(VideoDmo), CVideoDmo<\/span>)<\/pre>\n
But we don’t need this this time as we don’t need standard COM registration for the class. We will register its class object manually and temporarily, at the time of DMO initialization:<\/p>\n
CComQIPtr<<\/span>IBaseFilter><\/span> pBaseFilter;<\/span>\r\nCVideoDmo*<\/span> pVideoDmo;<\/span>\r\n{<\/span>\r\n    BEGIN_OBJECT_MAP(<\/span>g_pObjectMap)<\/span>\r\n        OBJECT_ENTRY(<\/span>__uuidof<\/span>(<\/span>CVideoDmo)<\/span>,<\/span> CVideoDmo)<\/span>\r\n    END_OBJECT_MAP(<\/span>)<\/span>\r\n    ATLASSERT(<\/span>DIM(<\/span>g_pObjectMap)<\/span> =<\/span>=<\/span> 2<\/span> &<\/span>&<\/span> !<\/span>g_pObjectMap[<\/span>1<\/span>]<\/span>.<\/span>pclsid)<\/span>;<\/span>\r\n    ATLENSURE_SUCCEEDED(<\/span>g_pObjectMap[<\/span>0<\/span>]<\/span>.<\/span>RegisterClassObject(<\/span>CLSCTX_INPROC_SERVER,<\/span> REGCLS_SINGLEUSE)<\/span>)<\/span>;<\/span>\r\n    _ATLTRY\r\n    {<\/span>\r\n        CComPtr<<\/span>IDMOWrapperFilter><\/span> pDmoWrapperFilter =<\/span> ConstructDmoWrappedFilter(<\/span>__uuidof<\/span>(<\/span>CVideoDmo)<\/span>,<\/span> CVideoDmo::<\/span>GetCategory(<\/span>)<\/span>)<\/span>;<\/span>\r\n        pBaseFilter =<\/span> pDmoWrapperFilter;<\/span>\r\n        ATLENSURE_THROW(<\/span>pBaseFilter,<\/span> E_NOINTERFACE)<\/span>;<\/span>\r\n        CComQIPtr<<\/span>IMediaObject><\/span> pMediaObject =<\/span> pDmoWrapperFilter;<\/span>\r\n        ATLENSURE_THROW(<\/span>pMediaObject,<\/span> E_NOINTERFACE)<\/span>;<\/span>\r\n        pVideoDmo =<\/span> static_cast<\/span><<\/span>CVideoDmo*<\/span>><\/span>(<\/span>(<\/span>IMediaObject*<\/span>)<\/span> pMediaObject)<\/span>;<\/span>\r\n    }<\/span>\r\n    _ATLCATCHALL(<\/span>)<\/span>\r\n    {<\/span>\r\n        ATLVERIFY(<\/span>SUCCEEDED(<\/span>g_pObjectMap[<\/span>0<\/span>]<\/span>.<\/span>RevokeClassObject(<\/span>)<\/span>)<\/span>)<\/span>;<\/span>\r\n        _ATLRETHROW;<\/span>\r\n    }<\/span>\r\n    ATLVERIFY(<\/span>SUCCEEDED(<\/span>g_pObjectMap[<\/span>0<\/span>]<\/span>.<\/span>RevokeClassObject(<\/span>)<\/span>)<\/span>)<\/span>;<\/span>\r\n}<\/span>\r\npVideoDmo-<\/span>><\/span>Initialize(<\/span>CDmoMediaType(<\/span>m_pMediaType)<\/span>,<\/span> CopyYv12MediaBuffer)<\/span>;<\/span>\r\nATLENSURE_SUCCEEDED(<\/span>pGraphBuilder-<\/span>><\/span>AddFilter(<\/span>pBaseFilter,<\/span> CStringW(<\/span>_T(<\/span>\"<\/span>Pass-Through DMO<\/span>\"<\/span>)<\/span>)<\/span>)<\/span>)<\/span>;<\/span>\r\nATLENSURE_SUCCEEDED(<\/span>pGraphBuilder-<\/span>><\/span>Connect(<\/span>pOutputPin,<\/span> _FilterGraphHelper::<\/span>GetFilterPin(<\/span>pBaseFilter,<\/span> PINDIR_INPUT)<\/span>)<\/span>)<\/span>;<\/span>\r\npOutputPin =<\/span> _FilterGraphHelper::<\/span>GetFilterPin(<\/span>pBaseFilter,<\/span> PINDIR_OUTPUT)<\/span><\/pre>\n
What is being done in the code snippet above is:<\/p>\n