mirror of
https://github.com/mpv-player/mpv.git
synced 2024-09-19 19:42:24 +02:00
59478b0059
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.
29 lines
817 B
C
29 lines
817 B
C
#pragma once
|
|
|
|
#include "filter.h"
|
|
|
|
// 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;
|
|
|
|
// The underlying format of uploaded frames
|
|
int selected_sw_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 {
|
|
struct mp_filter *f;
|
|
|
|
struct mp_image_pool *pool;
|
|
};
|
|
|
|
struct mp_hwdownload *mp_hwdownload_create(struct mp_filter *parent);
|