GNOME Bugzilla – Bug 781866
gstreamer-vaapi fails to build against libva version 0.99.0
Last modified: 2017-05-02 15:59:24 UTC
Version 0.99.0 of libva isn't currently supported by gstreamer-vaapi, so fail in the configure step instead of later in the build.
Created attachment 350604 [details] [review] [PATCH gstreamer-vaapi] build: Require libva < 0.99.0 libva >= 0.99.0 is not currently supported by gstreamer-vaapi, so fail to configure instead of failing late in the build.
Created attachment 350605 [details] [review] [PATCH gst-build] require libva < 0.99.0 for gstreamer-vaapi Version 0.99.0 of libva isn't currently supported by gstreamer-vaapi.
The patch looks fine, I was thinking to push it. But found that there is a 0.99.0 version of libva which can compile against gstreamer-vaapi if we only comment out vaSetInfoCallback() in gstvaapiutils. So the question is: Do we put a tight dependency to official opensource libva releases or just allow to build(or try to build) with any VA-APIs(eg: va headers bundled in MSDK) available ?
I think this is a bug in that specific library, with API version 0.99.0 How does it announce themselves as a libva but removing symbols from the official libva??? In my opinion the API clients shouldn't fix that.
(In reply to Víctor Manuel Jáquez Leal from comment #4) > I think this is a bug in that specific library, with API version 0.99.0 > > How does it announce themselves as a libva but removing symbols from the > official libva??? I think at worst you could say that that instance of the library isn't semantically versioned, but there is some precedent for minor versions from .90 up being the unstable lead up to a new (incompatible) major version, gtk or wayland for examples. At any rate I don't think it's necessary to draw a line in the sand about semantic versioning, it's versioned at least so let's use the version numbers to test for compatibility.
(In reply to Scott D Phillips from comment #5) > (In reply to Víctor Manuel Jáquez Leal from comment #4) > > I think this is a bug in that specific library, with API version 0.99.0 > > > > How does it announce themselves as a libva but removing symbols from the > > official libva??? > > I think at worst you could say that that instance of the library isn't > semantically versioned, but there is some precedent for minor versions from > .90 up being the unstable lead up to a new (incompatible) major version, gtk > or wayland for examples. At any rate I don't think it's necessary to draw a > line in the sand about semantic versioning, it's versioned at least so let's > use the version numbers to test for compatibility. Point taken, it's unstable API. And gstreamer-vaapi has done a good job catching that incompatibility ;) My worry about these tweaks per specific versions is that we can lose control (even more :)) of the used API, if we don't draw a line. At least in upstream. Nevertheless, if we are going to take that path, we should do it a code level, guarding the usage of that API (which now is only for logging) for that libva version. Dunno.
(In reply to Víctor Manuel Jáquez Leal from comment #6) > Nevertheless, if we are going to take that path, we should do it a code > level, guarding the usage of that API (which now is only for logging) for > that libva version. Dunno. Sree had the same thought too, but I believe there are breakages with the 0.99 version beyond just build breakages, and fixing up the build might make it look like it works when it actually doesn't. Better to just refuse to play with that version at all until someone goes through and actually makes it work. Also I think just blacklisting 0.99 will probably do more to influence it towards good behavior than only fixing up the the build breakage. Anyway that's the case I want to make. If it's not convincing to you and Sree then I can make the patch to check the version around vaSetInfoCallback.
Last time when I was testing with MSDK-libva , it required the below changes to get something working: https://cgit.freedesktop.org/~sree/gstreamer-vaapi/log/?h=iHD_driver Yesterday I was testing against the private staging branch (which I believe, is something similar to what we maintained in FDO years ago) and found that vaSetInfoCallback() is the only incompatible api. Note: Staging branch has VA version 0.99.0, we are not maintaining any staging branch in upstream libva hosted in github nowadays.
Comment on attachment 350604 [details] [review] [PATCH gstreamer-vaapi] build: Require libva < 0.99.0 after talking with Sree, this approach seems to be the most sane to avoid these futuristic libva implementations, and keep aligned with the official implementation. Please add in the commit log where this 0.99.0 version comes from and why it is rejected by gstreamer-vaapi.
commit 33888bf534400d3ea3ad7f4c9041ed835076fcc0 Author: Scott D Phillips <> Date: Thu Apr 27 22:55:27 2017 -0700 build: Require libva < 0.99.0 libva >= 0.99.0 is not currently supported by gstreamer-vaapi, so fail to configure instead of failing late in the build. This libva is bundled in msdk[1] and it is ahead in time with respect the official and open source libva[2]. GStreamer-VAAPI only supports the latter for now. 1. https://software.intel.com/en-us/media-sdk/download 2. https://github.com/01org/libva/ https://bugzilla.gnome.org/show_bug.cgi?id=781866
In gst-build: commit 4db18a66b415f794ee5500da589e719b77a39a19 Author: Scott D Phillips <scott.d.phillips@intel.com> Date: Thu Apr 27 22:58:35 2017 -0700 require libva < 0.99.0 for gstreamer-vaapi Version 0.99.0 of libva isn't currently supported by gstreamer-vaapi. https://bugzilla.gnome.org/show_bug.cgi?id=781866