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, 5 insertions, 0 deletions

diff --git a/video/hwdec.h b/video/hwdec.h
index f3f2df06f2..44008dece0 100644
--- a/video/hwdec.h
+++ b/video/hwdec.h
@@ -18,6 +18,11 @@ struct mp_hwdec_ctx {
     const int *supported_formats;
     // HW format used by the hwdec
     int hw_imgfmt;
+
+    // The name of this hwdec's matching conversion filter if available.
+    // This will be used for hardware conversion of frame formats.
+    // NULL otherwise.
+    const char *conversion_filter_name;
 };
 
 // Used to communicate hardware decoder device handles from VO to video decoder.