YUV422 to RGB24 using Intel Performance Primitives
If your function is called with non-aligned memory, it will allocate two buffers, copy, do the simple fast thing, copy again, and free. That’s a whole lotta work for something simple and fast. And if the step sizes don’t match, the copy will be even slower.

If this the normal execution case, I can imagine this being a significant drain on resources.

You are processing video. Each frame will have the same size. You can keep the internal buffers in this function around from call to call, so you can reuse them and avoid the mallocs.

But even better would be to directly read your video into aligned memory, in the right format for the IPP library. Your functions should just error out if the input pointers are not aligned.

Furthermore, the output data is stored in memory newed. You should pass a data pointer from the caller to write in. If you don’t want to do that, why not directly allocate this output buffer with the right alignment?

I would recommend skipping all the step computations and worries, simply setting

size.width = width * height;
size.height = 1;


If the IPP function believes all pixels are on a single row, then you don't need those padding bytes at the end of odd-sized rows.



There is a bug: In the case that malloc fails, (imgYUV422_IPP == NULL), you free a NULL pointer. Here you probably intended to free the rgbImg buffer if it was allocated earlier.

Similarly, pBGR is never freed on error.