renderer: add pl_render_image_ex and pl_render_image_mix_ex

To allow feedback on the inferred target colorspace. This allow users to validate the parameters.

added 2 commits

• 409ff01a - renderer: add pl_render_image_ex and pl_render_image_mix_ex
• b5a66e2b - d3d11/formats: set fmt->fourcc for consistency

Compare with previous version

added 2 commits

• 04e7927c - renderer: add pl_render_image_ex and pl_render_image_mix_ex
• 4f826d55 - d3d11/formats: set fmt->fourcc for consistency

Compare with previous version

I'm not happy with this design and it breaks convention of other _ex params for being extensible variants.

If I had to suggest a design, I'd probably suggest we add a new API like pl_render_fix_frame / pl_render_fix_frame_mix or w/e which will do all the same internal verification and fixup stuff (including moving crops to target and whatnot) in-place.

And then we obviously make pl_render_image / pl_render_image_mix re-use this same function internally, to avoid code duplication.

I can give ^ a shot tomorrow

I see your point. In fact I wanted to keep changes minimal, so I went with simple const removing approach.

Also I like my approach simply because it ensures that the feedback that we get is exactly what was used by libplacebo. Not requiring another API and/or logic to precompute that.

You know I could re-implement the logic using pl_color_space_infer_map and whatnot in mpv, but I don't like the idea of precomputing this values, rather than just returning them. In the event something changes in libplacebo, some new metadata is added, it will desync and so on. (also it is less code in both libplacebo and mpv to handle it this way)

I think it is neat to update target params in user provided struct. Maybe _ex is not best, but this was 5 minutes patch, so feel free to propose better one. But I feel like it is really unnecessary to introduce new API/logic to get values that are already there anyway.

I was thinking, something we also duplicate a lot is logic to find the "current" frame from a pl_frame_mix. If we have an API like this:

pl_renderer_infer_frame_mix(const struct pl_frame_mix *mix, struct pl_frame *target, struct pl_frame *out_image);
pl_renderer_infer_frame(struct pl_frame *image, struct pl_frame *target);

Then the infer_frame_mix variant can also be used to effectively get the "reference" pl_frame from the pl_frame_mix, same as what pl_render_image_mix does internally at the start of rendering.

mentioned in commit 913d1acb

mentioned in merge request !575 (merged)

Does !575 (merged) address your use case?

As an added bonus, you could now even nestle custom logic in between pl_frames_infer and pl_render_image, e.g. say you want to add more overlays after you already know the corrected crop size.

mentioned in commit a0752436

mentioned in commit 5832d29d

mentioned in commit 8dcbc6ea

mentioned in commit d8d02c5e

closed