Please note as of Wednesday, August 15th, 2018 this wiki has been set to read only. If you are a TI Employee and require Edit ability please contact x0211426 from the company directory.

Accessing Pixels in a Frame on the DM643x

From Texas Instruments Wiki
Jump to: navigation, search

A common question that has come up from time to time on the DM643x platform is, how can one modify the pixels in frame using the frame buffer pointer structure that is provided by the video driver, this article intends to answer this with a brief explanation and a modified example from the DM643x DVSDK.

Accessing the Frame

When working with video frames on the DM643x devices you will most likely be using the FVID API provided by the video driver. This API allows you to configure the incoming and outgoing video stream as well as extract a video frame from the capture side or provide a new frame to the display side. Typically this is done with a loop that has a call or two to FVID_exchange(). A call to FVID_exchange() allows your application code to swap a video buffer with the video driver by way of the second argument with a frame buffer pointer, either for capture or display pending the first argument. With the DM643x drivers this frame buffer pointer is actually a structure that contains quite a bit of information in addition to the pointer to the location of the video frame, therefore you have to access into that structure to get the pointer to the frame that you can use for accessing it.

The simple way to access the frame buffer itself is to reach into the structure with frameBuffPtr->frame.frameBufferPtr. This will return the address of the current frame you recently swapped or plan to swap with FVID_exchange(). You can also type cast it to a type you find more useful, below is a small example of extracting the frame buffer pointer from a FVID_exchange() call.

int* framepointer;
FVID_exchange(hGioVpfeCcdc, &frameBuffPtr);
framepointer = (int*)(frameBuffPtr->frame.frameBufferPtr);

Note the frame you are now pointing to is an interleaved YCbCr 4:2:2 stream, so every other byte is a Y, every 4th byte is a Cb, and every other 4th byte is a Cr (i.e. Cb Y Cr Y Cb Y Cr Y Cb Y...), which also means the size of the buffer will be your frame width x height x 2 bytes per pixel.

One more potential issue to keep in mind with these buffers is cache coherency. Because the buffers are being filled by the VPSS directly in external memory, the cache is not aware that the data has changed until you tell it so. In the default video preview example there are no cache coherency operations, because since the CPU never actually touches the frame buffers the cache is not involved. However, once you start touching pixel values in the frame you have the potential that the value you are accessing is not the latest value (you are still looking at old cached data) or that the modifications do not make it to the display in time (the display video frame goes out before the cached data is written to external memory). To avoid this you will want to invalidate the cache before working with a new frame from the capture, and to writeback the cache before giving up your modified buffer to the display.

An Example

The code example (updated 11/09/2009) is a modification of the video preview example that can be found within C:\dvsdk_x_xx_xx_xx\examples\video_preview\evmDM6437 of a DM6437 EVM DVSDK install. It is meant only to exercise the ability to modify a video frame, and does little of any practical use outside of that, though it does provide some interesting video output. Though the entire project is attached you can probably just take the video_preview.c file and copy it into your existing video preview example. Note that if you are using this project that it has dependencies that will be met by placing it within C:\dvsdk_x_xx_xx_xx\examples of a DM6437 EVM DVSDK install, otherwise you may have to adjust some paths so it picks up the proper libraries and headers.

Version 1.03 fixes build issues with DVDSK, there is now a #define PSP_1_10 in video_preview.c to manage some differences with the 1.10 PSP included in DVSDK Out of the box this release should build with a default install.