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.

[D-Ogi]

Fixed the MinGW build: %zu is not supported by MSVCRT's printf which is what MinGW uses under the hood. Replaced with %llu + explicit cast.

[ddennedy]

You need to get at least some build workflows to actually build this (not all). For example,

• .github/workflows/build-distros.yml: Add libplacebo-dev to Ubuntu and Debian, and add libplacebo-devel to Fedora 42 (I do not think one is available for Fedora 38).
• .github/workflows/build-linux.yml: Add the libplacebo-dev package for the build-cmake job.
• .github/workflows/build-msys2-mingw64.yml: Add the mingw-w64-x86_64-libplacebo package.

Replaced with %llu + explicit cast.

Our codebase generally prefers the macros %" PRIu64 " and %" PRId64 " from <inttypes.h>.

[D-Ogi]

Done. Added libplacebo packages to the three workflows, switched to PRIu64/PRId64 from <inttypes.h>, and added a minimum version requirement (libplacebo>=5.229) in the module's CMakeLists so older distros like Ubuntu 22.04 (ships v4.192) skip the module instead of failing.

Verified on my fork - all green: MSYS2 MinGW64, Ubuntu 24.04, 22.04, Debian stable/testing/unstable, Fedora 42, 38.

[D-Ogi]

Hi Dan, could I ask if you have an estimated timeline for the next round of review? This PR is a key enabler for my downstream work. The shader filters support lets Kdenlive reproduce After Effects preset pipelines and opens the door for the community to write custom GPU shaders within MLT.

[ddennedy]

In about 10 days as I’m on vacation

[ddennedy]

Something for you to comment on or think about until then. I have not looked closely enough. What happens when multiple placebo MLT filters are used on a producer? Does it transfer the image from RAM to GPU and back to RAM for each filter?

[D-Ogi]

Currently each filter does a full RAM -> GPU -> RAM roundtrip per frame. The flow for N chained placebo filters looks like this:

RAM (producer image)
-> GPU upload -> GPU render -> GPU download -> RAM (filter 1)
-> ... -> ... -> ...- > RAM (filter 2)
-> ...-> ... -> ... -> RAM (filter 3)

So with 3 filters that's 6 CPU <-> GPU transfers instead of the ideal 2 (one upload at the start, one download at the end).
The singleton gpu_context shares the pl_gpu, pl_renderer, and pl_dispatch across all filter instances, so there's no redundant GPU initialization. But... each filter creates temporary textures, uploads the RAM buffer, processes, downloads back to RAM, and destroys the textures.

The reason is that MLT's mlt_frame_get_image() contract is fundamentally CPU-buffer-based. And I think no way for a filter to pass a GPU texture handle to the next filter in the chain. To eliminate the intermediate transfers, the frame would need to carry a "GPU-resident image" flag and a texture reference that downstream filters can reuse, with only the last filter in the chain (or the consumer) performing the final download. That's a non-trivial change to MLT's image passing architecture.

I could attempt to implement this, for example by attaching a pl_tex to the frame via mlt_properties_set_data and having each placebo filter check for an existing GPU texture before uploading from RAM. The last consumer or non-placebo filter would trigger the download. But I'd rather hear your thoughts on the right approach before going down that path, since it touches assumptions about frame ownership and lifetime that you know much better than I do.

[D-Ogi]