[GST WATERMARK] support gvawatermark blurring on GPU

[walidbarakat]

Description

Enable GaussianBlur on VA surface (GPU) path in gvawatermark, allowing object blurring without falling back to CPU when the pipeline uses hardware-accelerated decode/encode.

How Has This Been Tested?

using gstreamer pipeline :

gst-launch-1.0 filesrc location=input_video.mp4 ! parsebin ! vah264dec ! gvadetect model=model.xml device=GPU pre-process-backend=va-surface-sharing ! gvawatermark device=GPU displ-cfg="enable-blur=true" ! vah264enc ! h264parse ! mp4mux ! filesink location=output_video.mp4

Checklist:

• I agree to use the MIT license for my code changes.
• I have not introduced any 3rd party components incompatible with MIT.
• I have not included any company confidential information, trade secret, password or security token.
• I have performed a self-review of my code.

[brmarkus]

useOpenCL: It checks initialization, not hardware. It returns true if OpenCL has been successfully initialized and is globally enabled within the binary. It means the framework is active. It confirms that OpenCV can route processing through OpenCL Transparent API instead of the standard CPU fallback.
But it's not a guarantee that OpenCL processing happens on a GPU.

[brmarkus]

cv::ocl::Device device = cv::ocl::Device::getDefault();

if (device.type() == cv::ocl::Device::TYPE_GPU) {
std::cout << "Success: OpenCL is using the GPU!\n";
std::cout << "Device Name: " << device.name() << "\n";
} else if (device.type() == cv::ocl::Device::TYPE_CPU) {
std::cout << "Notice: OpenCL is initialized, but running on the CPU.\n";
} else {
std::cout << "OpenCL is using an alternative device type.\n";
}

[walidbarakat]

you have a valid point here, but at line 472 cv::va_intel::ocl::initializeContextFromVA(self->va_dpy, /*interop*/ true); this function creates the OpenCL context using the cl_intel_va_api_media_sharing extension, which requires the GPU OpenCL device that shares memory with the VA display. It cannot produce a CPU OpenCL device — there's no VA-API/CPU-OpenCL interop path. After this call, cv::ocl::Device::getDefault().type() will always be TYPE_GPU

[brmarkus]

Thank you for the clarification

[tbujewsk]

Let's do not keep the same logic in two places, use here renderer_cpu.cpp::computeBlurKernelSize()

So:

• move the computeBlurKernelSize out of the anonymous namespace {} block in renderer/cpu/renderer_cpu.cpp
• add #include <opencv2/core.hpp> and a forward declaration: of cv::Size computeBlurKernelSize in renderer_cpu.h
• include the renderer/cpu/renderer_cpu.h in gstgvawatermarkimpl.cpp

[walidbarakat]

i got your point. i just have committed a classic DRY sin :D

however, i'm concerned about your suggestion that it may lead to more subtle issue with mixing the renderer-layer renderer_cpu.h with element-layer gstgvawatermarkimpl.cpp let's not do that. as it it can cause a coupling direction. however, you've the right point. so i suggest to move computeBlurKernelSize to render_prim.h to logically group it with Blur structure definition and as an already shared header between both CPU and GPU execution path.