hwtransfer: implement support for hw->hw format conversion

Historically, we have not attempted to support hw->hw format conversion
in the autoconvert logic. If a user needed to do these kinds of
conversions, they needed to manually insert the hw format's conversion
filter manually (eg: scale_vaapi).

This was usually fine because the general rule is that any format
supported by the hardware can be used as well as any other. ie: You
would only need to do conversion if you have a specific goal in mind.

However, we now have two situations where we can find ourselves with a
hardware format being produced by a decoder that cannot be accepted by
a VO via hwdec-interop:
 * dmabuf-wayland can only accept formats that the Wayland compositor
   accepts. In the case of GNOME, it can only accept a handful of RGB
   formats.
 * When decoding via VAAPI on Intel hardware, some of the more unusual
   video encodings (4:2:2, 10bit 4:4:4) lead to packed frame formats
   which gpu-next cannot handle, causing rendering to fail.

In both these cases (at least when using VAAPI with dmabuf-wayland), if
we could detect the failure case and insert a `scale_vaapi` filter, we
could get successful output automatically. For `hwdec=drm`, there is
currently no conversion filter, so dmabuf-wayland is still out of luck
there.

The basic approach to implementing this is to detect the case where we
are evaluating a hardware format where the VO can accept the hardware
format itself, but may not accept the underlying sw format. In the
current code, we bypass autoconvert as soon as we see the hardware
format is compatible.

My first observation was that we actually have logic in autoconvert to
detect when the input sw format is not in the list of allowed sw
formats passed into the autoconverter. Unfortunately, we never populate
this list, and the way you would expect to do that is vo-query-format
returning sw format information, which it does not. We could define an
extended vo-query-format-2, but we'd still need to implement the
probing logic to fill it in.

On the other hand, we already have the probing logic in the hwupload
filter - and most recently I used that logic to implement conversion
on upload. So if we could leverage that, we could both detect when
hw->hw conversion is required, and pick the best target format.

This exercise is then primarily one of detecting when we are in this
case and letting that code run in a useful way. The hwupload filter is
a bit awkward to work with today, and so I refactored a bunch of the
set up code to actually make it more encapsulated. Now, instead of the
caller instantiating it and then triggering the probe, we probe on
creation and instantiate the correct underlying filter (hwupload vs
conversion) automatically.

1 files changed, 10 insertions, 7 deletions

diff --git a/filters/f_hwtransfer.h b/filters/f_hwtransfer.h
index 4f6c253193..dde9cf7137 100644
--- a/filters/f_hwtransfer.h
+++ b/filters/f_hwtransfer.h
@@ -4,16 +4,19 @@
 
 // A filter which uploads sw frames to hw. Ignores hw frames.
 struct mp_hwupload {
+    // Indicates if the filter was successfully initialised, or not.
+    // If not, the state of other members is undefined.
+    bool successful_init;
+
+    // The filter to use for uploads. NULL if none is required.
     struct mp_filter *f;
-};
 
-struct mp_hwupload *mp_hwupload_create(struct mp_filter *parent, int hw_imgfmt);
+    // The underlying format of uploaded frames
+    int selected_sw_imgfmt;
+};
 
-// Return the best format suited for upload that is supported for a given input
-// imgfmt. This returns the same as imgfmt if the format is natively supported,
-// and otherwise a format that likely results in the least loss.
-// Returns 0 if completely unsupported.
-int mp_hwupload_find_upload_format(struct mp_hwupload *u, int imgfmt);
+struct mp_hwupload mp_hwupload_create(struct mp_filter *parent, int hw_imgfmt,
+                                       int sw_imgfmt, bool src_is_same_hw);
 
 // A filter which downloads sw frames from hw. Ignores sw frames.
 struct mp_hwdownload {