libplacebo integration with mpv

[Obegg]

(This can be very well be a stupid question, and I am not an expert)

I noticed that libplacebo added ewa_lanczossharp (merge request) That means that in order to use it you'll have to use libplacebo-opts=upscaler=ewa_lanczos4sharpest Great, so far I understand.

Now, because that's a libplacebo option, and not a mpv option, you can't use scale=ewa_lanczos4sharpest, So it has to be added by pull request which will copy-paste the values from libplacebo to mpv. This is the part which I 50% understand and makes me wonder why this feature (in this case: ewa_lanczos4sharpest) to be "added" twice.

Can't mpv (or libplacebo) just read one another and be "unified" (if that makes sense)?

I believe this is what's called an API (could be wrong).

I'm not saying that I know what I'm talking about, I'm just saying that it looks like everything that is changing on libplacebo end has to change (again) over on mpv. I'm just thinking there must be a better way for changes in libplacebo to be integrated with mpv.

Example: mpv will "read" libplacebo upscalers (which in this case are const struct pl_filter_config * const pl_filter_configs[] = { (if I'm not mistaken) from here https://code.videolan.org/videolan/libplacebo/-/blob/master/src/filters.c#L891 ) and it order to use them - mpv will remove the prefix pl_filter_ to be able to remain backward compatiable with the current scale options, and now users will be able to use every upscaler from libplacebo. (please ignore the fact that they already can use them by using libplacebo-opts=upscaler=)

This was just an example, I could be entirely wrong and possibly made myself look stupid here, but I do want to help if I can. This is not the first time I've noticed changes that have to be "applied" twice.

[haasn]

This would be considerably easier to do if not for the existence of vo_gpu, which vo_gpu_next still has to share its options parsing code with. --scale is a perfect example, because it goes through validate_scaler_opt which only reads from the vo_gpu list of scalers to check what the valid values are. So even if libplacebo supports some scalers that mpv doesn't, the fact that vo_gpu doesn't support those scalers is exactly what prevents vo_gpu_next from automatically picking them up.

Without vo_gpu we could simply delete all of these options and create an options bridge, or define a much more lightweight way of mapping them to their libplacebo analogs.

[Obegg]

Great explanation, thank you! I would like to discuss it more, if you'll allow me.

I remember seeing a comment somewhere about the topic of deprecate vo_gpu, but I don't remember exactly what has been said. I am aware of the GPU Next vs GPU wiki but I don't know the EXACT details about why mpv shouldn't deprecate vo_gpu yet. While vo_gpu is old (I remember seeing a comment saying the the developer quit or something along those lines), if I understand correctly it has libmpv (which I've yet to figure out what that is, but that's off-topic, I guess?), while vo_gpu_next doesn't have libmpv (which it says "There is currently no support for the libmpv") So I guess mpv has to keep vo_gpu untill libmpv is added to vo_gpu_next?

Either way, there are alot of reasons to use vo_gpu_next, like Dolby Vision, as one example. I use vo_gpu_next since it was first introduced and whenever I had issues I reported them, in order to improve it and help as much as I can, but I guess there are many reasons (which I've yet to know) why it's not replacing vo_gpu, which I would like to know.

Looking forward, from a different point of view: vo_gpu is old while vo_gpu_next is new. vo_gpu is the default while vo_gpu_next is experimental. vo_gpu existence makes vo_gpu_next hard to implement (features have to be "added" twice). vo_gpu doesn't support Dolby Vision while vo_gpu_next does. vo_gpu has libmpv while vo_gpu_next doesn't. vo_gpu developer quit while vo_gpu_next developer is active. Simply looking at those facts (if I got them right) without any feelings of hate or love towards each vo seems like to best option will be to "invest" in vo_gpu_next in the long-term. (A stupid example will be to compare Windows 7 vs Windows 10, the 7 is old and out of support while 10 is "new" and in support)

[llyyr]

libmpv allows you to use the mpv rendering mechanisms to build your own video player, see downstream projects like Celluloid or Haruna or mpc-qt for example which utilize libmpv. Not to mention macOS support on mpv itself currently relies on libmpv. You can't use gpu-next on Mac.

There's also a issues with opengl performance with gpu-next, but this one's minor.

vo_gpu developer quit while vo_gpu_next developer is active.

There wasn't really a specific "vo_gpu developer", most of the work on it was done jointly by wm4 and haasn.

So I guess mpv has to keep vo_gpu until libmpv is added to vo_gpu_next?

This is an if, not a when. Based on what I gathered from discussions, nobody is interested in doing the work that comes with trying to integrate gpu-next with libmpv so someone else has to step up for it to get done most likely.

[Obegg]

Interesting... this was very informative, thank you.

I will close this "issue" (question) now.