Add libplacebo GPU module with render and shader filters

[D-Ogi]

Summary

New module placebo providing GPU-accelerated video processing via libplacebo:

• placebo.render — GPU scaling (ewa_lanczos, lanczos, mitchell, etc.), debanding, dithering (blue noise, ordered LUT), and tonemapping (auto, clip, mobius, reinhard, hable, bt.2390, spline) with quality presets (fast/default/high_quality)
• placebo.shader — Custom mpv-compatible .hook shader support with hot-reload on file change

Architecture

• Singleton GPU context (gpu_context.c) with thread-safe initialization and render locking
• Backend priority: D3D11 (Windows) → Vulkan → OpenGL
• Vulkan loader dynamically loaded on Windows when libplacebo is built without vk-proc-addr support
• Shader cache persisted to disk for faster subsequent startups
• Graceful passthrough when no GPU is available

Build

Controlled by MOD_PLACEBO CMake option (default ON). Requires libplacebo via pkg-config. Optionally links D3D11/DXGI when PL_HAVE_D3D11 is detected at configure time. MSVC builds link PThreads4W.

Files (10 total)

File	Description
CMakeLists.txt	+1 line: MOD_PLACEBO option
src/modules/CMakeLists.txt	+4 lines: placebo subdirectory
src/modules/placebo/CMakeLists.txt	Module build config
src/modules/placebo/factory.c	Module registration
src/modules/placebo/gpu_context.h	GPU lifecycle API
src/modules/placebo/gpu_context.c	Singleton GPU init (D3D11/Vulkan/OpenGL)
src/modules/placebo/filter_placebo_render.c	Render filter implementation
src/modules/placebo/filter_placebo_render.yml	Render filter metadata
src/modules/placebo/filter_placebo_shader.c	Shader filter implementation
src/modules/placebo/filter_placebo_shader.yml	Shader filter metadata

Testing

Tested on Windows with D3D11 backend via Kdenlive. Verified:

• GPU initialization and fallback chain
• Render filter with default/fast/high_quality presets
• Shader filter with Anime4K and FSRCNNX .hook files
• Shader hot-reload on file modification
• Graceful passthrough when GPU is unavailable
• Shader cache persistence across sessions
• Thread safety under concurrent filter instances

[ddennedy]

How does this compare with using libplacebo through the existing avfilter?

[D-Ogi]

The main difference is the GPU context lifecycle. The avfilter wrapper creates a new AVFilterGraph per filter instance and vf_libplacebo initializes its own Vulkan device inside that graph. With multiple filters on a timeline you get multiple GPU contexts. The native module uses a process-wide singleton in gpu_context.c so one pl_gpu, one pl_renderer, one pl_dispatch shared across all instances.

The frame path is also shorter. The avfilter wrapper does two memcpy round-trips between MLT buffers and AVFrames (line-by-line with linesize conversion), on top of whatever vf_libplacebo does internally for GPU transfer. The native module calls pl_tex_upload/pl_tex_download directly on the MLT image pointer, no intermediate AVFrame.

A the most interesting part is the shader filter that doesn't have an avfilter equivalent. It loads mpv .hook files at runtime and checks file mtime on every frame so when the file changes on disk, it re-parses only the pl_hook object while keeping the GPU context alive. This is useful for iterative shader development in for instance an NLE where you want to edit a .hook file in a text editor and see the result on the timeline without restarting anything. The avfilter path would need a full graph rebuild to pick up a changed shader_path.

The trade-off is a direct build dependency on libplacebo vs getting it through FFmpeg. The module could be optional so wouldn't affect builds where libplacebo isn't available. Regarding the tests, at this time I don't have solid Linux/MacOS environments to test all the dependencies, but as I read from failed tests the root cause seems to be easy to fix.