GNOME Bugzilla – Bug 764673
blacklist unsupported backend drivers
Last modified: 2016-04-29 08:45:30 UTC
There are a lot of complains from users who try gstreamer-vaapi using unsupported/non-intel vaapi backends. We need to detect what backend is using the client and then we have two options: 1\ show a flashy warning that they are using an unsupported backend and some use case might not work at all. 2\ directly bail out the vaapi element and let the autoplug to choose another element.
I would go for option 2 for starters, perhaps with an environment variable that users can set to opt in in which case you can show a flashy warning to make sure they're aware that this may not work well.
That's a pity. We use gst-vaapi with vdpau-driver (on native NVIDIA driver + hardware) on several k installations which runs perfectly well for 'basic' video playback (vaapidecode ! vaapisink) for years. I don't follow gst-vaapi development closely for maybe the last 2 years, but guess that the reported problems come from recently added features like GL texture sharing, postprocessing etc. Would be great if a more fine-grained control of what is considered not working would be possible. Also with respect to the underlying hardware. E.g. our experiences with the open source radeon driver + mesa vdpau state tracker are very bad when it comes to long running playback and robustness with discontinuous video data.
(In reply to Holger Kaelberer from comment #2) > That's a pity. We use gst-vaapi with vdpau-driver (on native NVIDIA driver + > hardware) on several k installations which runs perfectly well for 'basic' > video playback (vaapidecode ! vaapisink) for years. > > I don't follow gst-vaapi development closely for maybe the last 2 years, but > guess that the reported problems come from recently added features like GL > texture sharing, postprocessing etc. > > Would be great if a more fine-grained control of what is considered not > working would be possible. > > Also with respect to the underlying hardware. E.g. our experiences with the > open source radeon driver + mesa vdpau state tracker are very bad when it > comes to long running playback and robustness with discontinuous video data. An environment variable as Tim mentioned shouldn't be an issue for you, right? Which means, in order to get HW decode/enc/vpp support, all non-intel backend users (until there is properly tested backends available) are supposed to enable the environment variable.
(In reply to sreerenj from comment #3) > > An environment variable as Tim mentioned shouldn't be an issue for you, > right? > Right
Created attachment 326320 [details] [review] vaapidecode: search driver in whitelist If the backend driver vendor string is not in a whitelist and the environment variable GST_VAAPI_ALL_DRIVERS is not set either, the decoder will not expose its source pad caps, rejecting to perform, so the auto-plug mechanism will look for another decoder.
Comment on attachment 326320 [details] [review] vaapidecode: search driver in whitelist What is the exact effect of this? The element is not registered, or only iwth NONE rank? The state change from NULL to READY fails? Caps are rejected?
(In reply to Sebastian Dröge (slomo) from comment #6) > Comment on attachment 326320 [details] [review] [review] > vaapidecode: search driver in whitelist > > What is the exact effect of this? The element is not registered, or only > iwth NONE rank? The state change from NULL to READY fails? Caps are rejected? sink getcaps will return empty caps. Is it a proper way to do it?
And setcaps will fail? It's not ideal, no :) Better fail as early as possible, e.g. during the state change.
I think general idea about the whilelist + the env var is good. Since the minimal libva version required at compile time is old (i.e. it requires libva > 0.30.4 in current mater: https://cgit.freedesktop.org/gstreamer/gstreamer-vaapi/tree/configure.ac#n35), it would be great to also check the actual version of the va-api backend at runtime, the one returned by vaInitialize. And also the driver name returned by vaGetDriverName: So: va_vendor_string + va_driver_name + min_va_version Also I would like to add the following entries in the whitelist: "mesa gallium vaapi", "nouveau", 0.38.0 "mesa gallium vaapi", "radeon", 0.38.0 If there are bugs in the gallium vaapi backend let's fix them. But I also understand that for you it is less priority so having these 3 infos (va_vendor_string + va_driver_name + min_va_version) in gst_vaapi_check_status: https://cgit.freedesktop.org/gstreamer/gstreamer-vaapi/tree/gst-libs/gst/vaapi/gstvaapiutils.c#n50 should help with bug triage.
(In reply to Julien Isorce from comment #9) > I think general idea about the whilelist + the env var is good. > Since the minimal libva version required at compile time is old (i.e. it > requires libva > 0.30.4 in current mater: > https://cgit.freedesktop.org/gstreamer/gstreamer-vaapi/tree/configure. > ac#n35), I think we should increase the libva version requirement in the configure.ac @Sree what do yo think? > it would be great to also check the actual version of the va-api > backend at runtime, the one returned by vaInitialize. And also the driver > name returned by vaGetDriverName: > > So: va_vendor_string + va_driver_name + min_va_version > > Also I would like to add the following entries in the whitelist: > "mesa gallium vaapi", "nouveau", 0.38.0 > "mesa gallium vaapi", "radeon", 0.38.0 > > If there are bugs in the gallium vaapi backend let's fix them. But I also > understand that for you it is less priority so having these 3 infos > (va_vendor_string + va_driver_name + min_va_version) in > gst_vaapi_check_status: > https://cgit.freedesktop.org/gstreamer/gstreamer-vaapi/tree/gst-libs/gst/ > vaapi/gstvaapiutils.c#n50 should help with bug triage. Interesting. Could you open a bug about this logging feature?
(In reply to Julien Isorce from comment #9) > And also the driver name returned by vaGetDriverName: There no such methon in VA-API :( The driver name is only used internally, but it is not exposed.
Created attachment 326499 [details] [review] vaapidecode: search driver in whitelist If the backend driver vendor string is not in a white-list, and the environment variable GST_VAAPI_ALL_DRIVERS is not set either, the decoder will change it state from NULL to READY, hence the auto-plug mechanism will look for another decoder. This patch assumes the GstContext has already being shared along the pipeline and the element has a valid GstVaapiDisplay instance.
Created attachment 326502 [details] [review] vaapidecode: search driver in whitelist If the backend driver vendor string is not in a white-list, and the environment variable GST_VAAPI_ALL_DRIVERS is not set either, the decoder will change it state from NULL to READY, hence the auto-plug mechanism will look for another decoder. This patch assumes the GstContext has already being shared along the pipeline and the element has a valid GstVaapiDisplay instance.
Created attachment 326533 [details] [review] vaapidecode: search driver in whitelist If the backend driver vendor string is not in a white-list, and the environment variable GST_VAAPI_ALL_DRIVERS is not set either, the decoder will change it state from NULL to READY, hence the auto-plug mechanism will look for another decoder. This patch assumes the GstContext has already being shared along the pipeline and the element has a valid GstVaapiDisplay instance.
Attachment 326533 [details] pushed as 53851b0 - vaapidecode: search driver in whitelist