vdxa_addingvdxasupport

VirtualDub Plugin SDK 1.2

Adding VDXA support to a video filter

Catching VDXA formats in paramProc

A video filter must accept one or more accelerated formats in paramProc to enable VDXA support. There are two VDXA formats:

kPixFormat_VDXA_RGB
The x, y, and z components of each pixel hold red, green, and blue values from 0-1. W (alpha) is undefined on read and ignored on write.

kPixFormat_VDXA_YUV
The x, y, and z components of each pixel hold chroma red, luma, and chroma blue, respectively. Chroma components range from 16/255 to 240/255, while luma ranges from 16/255 to 235/255. W (alpha) is undefined on read and ignored on write.

Filters can announce support for both CPU-based and VDXA formats, and this can be done based on configuration parameters, so a filter could offer VDXA support only when certain configuration options were activated. However, a filter must only work in VDXA or CPU formats entirely; it cannot accept a CPU format and output VDXA or vice-versa.

Currently, a filter operating in VDXA mode must operate in buffer swap mode (FILTERPARAM_SWAP_BUFFERS).

Handling startProc/endProc

The regular startProc and endProc entry points are called in VDXA mode, but the mpVDXA field of the VDXFilterActivation structure is set to a non-NULL pointer. When this is set, a video filter should create resources through the supplied IVDXAContext interface rather than allocating CPU-side buffers.

All VDXA resources must be released when endProc() exits. Failing to do so is a logic error that can halt rendering.

The VDXVideoFilter helper class of the VDXFrame library splits these entry points so that Start() and End() are only called for CPU mode, whereas StartAccel() and StopAccel() are called in VDXA mode. For convenience, the mpVDXA pointer is passed as a function parameter.

Handling runProc

In VDXA mode, accelRunProc is called instead of runProc. You must override accelRunProc even if you do no actual processing — otherwise, the host will not even offer you VDXA formats. However, it will not be called unless VDXA processing is actually active for that filter.

None of the usual memory pointers are valid in accelRunProc, including the data or pitch values of any buffer. All access to frame buffers must be done through VDXA interfaces and using the mVDXAHandle field of VDXFBitmap. No CPU access is permitted to any frame buffer. This is required since many of the intermediate frame buffers are held on the graphics accelerator in CPU inaccessible formats and memory.

When using VDXVideoFilter, override RunAccel() to handle main execution.

Threading changes

VDXA execution may occur on a separate thread from other video filters. However, the following are guaranteed:

startProc, endProc, and accelRunProc may run on a different thread but never run concurrently, i.e. are always serialized.
VDXA routines are always executed as if they were synchronous. That is, if you create a texture and receive a handle, that handle is immediately valid and remains so until the texture is destroyed.
When live preview is active in the filter's configuration dialog, the UI thread for the dialog stops processing messages while the filter is running startProc, endProc, or accelRunProc, even if those routines are executing on the VDXA thread. This prevents most UI events, including repainting, and avoids concurrent execution in the filter. (Exception: Sent messages may execute concurrently to avoid deadlock.)