After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 764673 - blacklist unsupported backend drivers
blacklist unsupported backend drivers
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer-vaapi
git master
Other Linux
: Normal normal
: 1.9.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on: 765368
Blocks:
 
 
Reported: 2016-04-06 10:02 UTC by Víctor Manuel Jáquez Leal
Modified: 2016-04-29 08:45 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
vaapidecode: search driver in whitelist (2.33 KB, patch)
2016-04-19 11:31 UTC, Víctor Manuel Jáquez Leal
none Details | Review
vaapidecode: search driver in whitelist (5.45 KB, patch)
2016-04-21 15:32 UTC, Víctor Manuel Jáquez Leal
none Details | Review
vaapidecode: search driver in whitelist (5.69 KB, patch)
2016-04-21 15:40 UTC, Víctor Manuel Jáquez Leal
none Details | Review
vaapidecode: search driver in whitelist (5.82 KB, patch)
2016-04-22 08:58 UTC, Víctor Manuel Jáquez Leal
committed Details | Review

Description Víctor Manuel Jáquez Leal 2016-04-06 10:02:40 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.
Comment 1 Tim-Philipp Müller 2016-04-06 10:06:18 UTC
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.
Comment 2 Holger Kaelberer 2016-04-06 10:28:46 UTC
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.
Comment 3 sreerenj 2016-04-14 09:24:58 UTC
(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.
Comment 4 Holger Kaelberer 2016-04-15 05:41:39 UTC
(In reply to sreerenj from comment #3)
> 
> An environment variable as Tim mentioned shouldn't be an issue for you,
> right?
>  

Right
Comment 5 Víctor Manuel Jáquez Leal 2016-04-19 11:31:48 UTC
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 6 Sebastian Dröge (slomo) 2016-04-19 11:51:26 UTC
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?
Comment 7 Víctor Manuel Jáquez Leal 2016-04-19 14:42:03 UTC
(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?
Comment 8 Sebastian Dröge (slomo) 2016-04-19 14:47:00 UTC
And setcaps will fail? It's not ideal, no :) Better fail as early as possible, e.g. during the state change.
Comment 9 Julien Isorce 2016-04-21 13:23:12 UTC
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.
Comment 10 Víctor Manuel Jáquez Leal 2016-04-21 13:34:34 UTC
(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?
Comment 11 Víctor Manuel Jáquez Leal 2016-04-21 14:02:42 UTC
(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.
Comment 12 Víctor Manuel Jáquez Leal 2016-04-21 15:32:05 UTC
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.
Comment 13 Víctor Manuel Jáquez Leal 2016-04-21 15:40:34 UTC
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.
Comment 14 Víctor Manuel Jáquez Leal 2016-04-22 08:58:17 UTC
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.
Comment 15 Víctor Manuel Jáquez Leal 2016-04-22 15:26:54 UTC
Attachment 326533 [details] pushed as 53851b0 - vaapidecode: search driver in whitelist