Hey Paul,

To provide some more context, we're trying to optimize one specific use case for now, converting dual-fisheye to equirectangular format in real-time. We're using it like this: v360=dfisheye:e:ih_fov=193:iv_fov=193.

As our project is running on a battery powered SBC (Orange Pi 5 Plus, running RK3588), we're quite constrained on resources. We've already optimized most of our FFmpeg pipeline, but the v360 filter is the biggest remaining resource hog.

Currently, we're able to run a single pipeline in real-time for a single video source, but in the future we'd like to extend that further to multiple real-time video sources, for which the CPU-based filter is going to be too heavy for on our environment.

If I understand it right, I think that neither EAC nor cubemap are used here, but I don't have experience with FFmpeg internals so I might be wrong. Is this use case something that the code you mentioned has previously supported? I understand that the code would need more work to support current libavfilter, so we're wondering if you'd be open to sponsorship to help us bring v360_opencl to support our use case?

Thanks!

No attempt was made to compile/test it with recent libavfilter.

It does not have EAC or cubemap support, among many other stuff.

On todays GPUs with GBs of GPU RAM whole remap data could be stored in memory like what CPU v360 filter does.

Then speed could be even faster?! or not...

On Fri, Feb 13, 2026 at 12:45 AM <milos@whitebox.aero> wrote:

Hey Paul,

Hope you're doing well. Just wanted to ask if you had time to check if
you still have the source code of `vf_v360_opencl.c`.

Thanks!