mpv icon indicating copy to clipboard operation
mpv copied to clipboard

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

Open Frechdachs opened this issue 2 years ago • 9 comments

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.

Frechdachs avatar Oct 29 '22 17:10 Frechdachs

I remember it was mentioned previousily. https://github.com/mpv-player/mpv/issues/9475

hooke007 avatar Oct 29 '22 18:10 hooke007

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.

Frechdachs avatar Oct 29 '22 19:10 Frechdachs

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.

RibShark avatar Sep 28 '23 17:09 RibShark

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.

Dudemanguy avatar Sep 28 '23 19:09 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.

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

haasn avatar Sep 28 '23 19:09 haasn

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.

GalaxySnail avatar Sep 28 '23 19:09 GalaxySnail

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.

Dudemanguy avatar Sep 28 '23 19:09 Dudemanguy

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

low-batt avatar Apr 05 '24 21:04 low-batt

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.

TingPing avatar Apr 08 '24 13:04 TingPing