Support for libplacebo (gpu-next) in the rendering API

[Frechdachs]

As of now, --vo=libmpv with the OpenGL backend has features roughly equivalent to --vo=gpu. Features only available in gpu-next are currently not available when using the rendering API. It would be nice if we could get support for a libplacebo-based backend in the rendering API.

Expected behavior of the wanted feature

An option to choose between using a gpu- or gpu-next-based OpenGL backend when using --vo=libmpv.

[hooke007]

I remember it was mentioned previousily.
#9475

[Frechdachs]

Yes, gpu-next can be used for embedding with the --wid option, but not with the rendering API. My use case requires the rendering API, unfortunately.

[RibShark]

This is an important issue for optimal support of HDR when mpv is embedded (since gpu-next greatly increases HDR usability). Embedding with --wid isn't always an option, especially now there is a strong push towards Wayland on the Linux desktop which cannot support window embedding in this way.

[Dudemanguy]

My problem with the render API is that it's like 1000+ lines of very awkward abstractions to only give you a fraction of the features the proper VO has and probably a bunch of bugs to boot. There's a reason virtually no one has touched it. And what's the use case exactly? Embedding the mpv window so you can draw your own context menus/GUI? You can do that with --wid which is like a handful of lines to implement in mpv and actually gives you the proper VO (gpu-next or gpu). There's several libmpv clients that use this method (off the top of my head, mpv.net did this) and I've never heard of any problems.

I'm aware that this won't work on wayland, and it seems like macOS doesn't support it either (correct me if I'm wrong). I don't know how much "working around bad platforms" we want to deal with. Even android allows foreign window embedding.

[haasn]

My problem with the render API is that it's like 1000+ lines of very awkward abstractions to only give you a fraction of the features the proper VO has and probably a bunch of bugs to boot. There's a reason virtually no one has touched it. And what's the use case exactly? Embedding the mpv window so you can draw your own context menus/GUI? You can do that with --wid which is like a handful of lines to implement in mpv and actually gives you the proper VO (gpu-next or gpu). There's several libmpv clients that use this method (off the top of my head, mpv.net did this) and I've never heard of any problems.

To the best of my knowledge, it is also what VLC does. The main playback window is embedded into a Qt application.

[GalaxySnail]

Maybe off-topic, but is it possible to implement something like --wid for wayland? AFAIK there is an XDG foreign protocol, but I'm not sure if it would be useful.

[Dudemanguy]

It's impossible currently. The xdg foreign protocol doesn't actually give you anything useful. There were a couple of issues about it in wayland protocols a while ago with not very positive results as usual.

Edit: Also some discussion on this mpv issue.

[low-batt]

The IINA project also uses the render API and is hoping this issue will be addressed soon.

[TingPing]

Celluloid also uses it. Its the only way to embed it in a Linux app basically. Pretending Wayland isn't used by many users and the default for many makes no sense.