[PATCH 0/1] MR2898: winegstreamer: Forbid vaapidecodebin when looking for a specific element.

[Rémi Bernon]

This will eventually fallback to vaapih264dec and similar decoders if
VA-API plugins are indeed available.

Split from https://gitlab.winehq.org/wine/wine/-/merge_requests/2893, as this doesn't have any effect unless VA-API plugins are installed, and they aren't on the testbot or Gitlab.

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/2898

[PATCH 1/1] winegstreamer: Forbid vaapidecodebin when looking for a specific element.

[Rémi Bernon]

From: Rémi Bernon <rbernon(a)codeweavers.com>

This will eventually fallback to vaapih264dec and similar decoders if
VA-API plugins are indeed available.
---
 dlls/winegstreamer/unixlib.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/dlls/winegstreamer/unixlib.c b/dlls/winegstreamer/unixlib.c
index 6ffd41e9712..6cdcfa6758a 100644
--- a/dlls/winegstreamer/unixlib.c
+++ b/dlls/winegstreamer/unixlib.c
@@ -101,6 +101,14 @@ GstElement *find_element(GstElementFactoryListType type, GstCaps *src_caps, GstC
     for (tmp = transforms; tmp != NULL && element == NULL; tmp = tmp->next)
     {
         name = gst_plugin_feature_get_name(GST_PLUGIN_FEATURE(tmp->data));
+
+        if (!strcmp(name, "vaapidecodebin"))
+        {
+            /* vaapidecodebin adds too much abstraction and wg_transform works best with lower-level elements. */
+            GST_WARNING("Ignoring vaapidecodebin decoder.");
+            continue;
+        }
+
         if (!(element = gst_element_factory_create(GST_ELEMENT_FACTORY(tmp->data), NULL)))
             GST_WARNING("Failed to create %s element.", name);
     }
-- 
GitLab

https://gitlab.winehq.org/wine/wine/-/merge_requests/2898

[Zebediah Figura (＠zfigura)]

> From the comments on 2893, I gather the reason for this is that vaapidecodebin appends a queue internally, and we don't want that.

I'm not thrilled about this, because this is fundamentally a problem of us wanting to control exactly how samples are buffered, and there's no guarantees on the GStreamer side. I'd rather be able to just force GStreamer, or some other library, to provide those guarantees to us. But in the absence of that, I'm willing to accept a patch that blacklists vaapidecodebin.

However, it will need a better comment than this. "Too much abstraction" is vague if not meaningless. "It introduces an internal queue object, whereas Windows programs depend on samples being available synchronously" actually explains the problem and why we can't easily work around it, for instance.

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/2898#note_33849