Memory Allocators with Blackmagic DeckLink video capture hardware

With all respect to Blackmagic Design products, there are bugs so painfully hard to identify. Capture board driver has specific requirements as for buffers allocated for captured video frames. The parameters of memory allocator in used are going in ALLOCATOR_PROPERTIES structure.

typedef struct _AllocatorProperties {
  long cBuffers; // 30
  long cbBuffer;
  long cbAlign; // 16
  long cbPrefix;
} ALLOCATOR_PROPERTIES;

The board is going to use 30 buffers (for a second of video specific capture with NTSC video) and the buffers have to have specific alignment. This is reasonable and goes well if the capture filter, backed in turn by WDM driver, runs with all defaults set and driver’s defaults apply.

As a part of buffer negotiation however, the capture filter queries its peer if there are other suggestions as for buffer allocation. There might be some, why not? Most of the filters don’t have any preferences and thus do fine, because default implementation on the input pin is E_NOTIMPL:

// what requirements do we have of the allocator - override if you want
// to support other people's allocators but need a specific alignment
// or prefix.
STDMETHODIMP
CBaseInputPin::GetAllocatorRequirements(__out ALLOCATOR_PROPERTIES*pProps)
{
    UNREFERENCED_PARAMETER(pProps);
    return E_NOTIMPL;
}

The problem is that that if there are any, esp. those for different alignment, the capture filter accepts them, prefers them to the ones he would use otherwise. Then when streaming starts he finds itself checking the properties of the allocator and as the check fails, the filter does not do any streaming without indicating any runtime error.

That’s it – you hit Start button and there is nothing but blackness, without any single video frame streamed through. And the reason is just downstream peer saying “well, I’d say two buffers on the allocator would be good for me – but since I am not responsible for final choice you can do whatever you think is okay”.

As the capture filter is responsible to choose the allocator and set it up, and alignment is so important for it, then why wouldn’t it negotiate and apply the values that would work? If it was unable to end with with negotiating anything meaningful, why would not it indicate a streaming error? It should have definitely done that.