GNOME Bugzilla – Bug 784398
Add support for VA-API 1.0
Last modified: 2017-08-25 14:49:05 UTC
VA-API/LibVA is preparing for the major non-API/ABI compatible release. These are the proposed changes:https://github.com/01org/libva/pull/75 Here is the development branch for libva and intel-vaapi-driver: https://github.com/01org/libva/tree/v2.0-branch https://github.com/01org/intel-vaapi-driver/tree/v2.0-branch We should prepare for supporing two of the libva ABI versions in gstreamer-vaapi, based on the above pull request.
Created attachment 355336 [details] [review] libs: decoder: h264: libva 1.0 deprecated baseline libva 1.0 deprecated H.264 baseline profile and FMO support (commit b4f332b3).
Created attachment 355337 [details] [review] libs: utils: libva 1.0 changed the logging The logging mechanism in libva has changed it's functions signatures. This patch updates that for libva versions >= 1.0
Created attachment 355338 [details] [review] build: blacklist only libva 0.99.0 Intel's MSDK uses libva 0.99.0, meanwhile open source libva bumped its API version to 1.0.0. Thus we have to blacklist only the MSDK's libva (0.99.0)
with this commit https://github.com/01org/libva/commit/9a148c7b72dca800cd382287b62df17aa22e0d72 everything changes: now libva-2.0 might be co-installed with libva *sigh*
Created attachment 356438 [details] [review] libs: decoder: h264: libva 1.0 deprecated baseline libva 1.0 deprecated H.264 baseline profile and FMO support (commit b4f332b3).
Created attachment 356439 [details] [review] libs: utils: libva 1.0 changed the logging The logging mechanism in libva has changed it's functions signatures. This patch updates that for libva versions >= 1.0
Created attachment 356440 [details] [review] build: blacklist only libva 0.99.0 Intel's MSDK uses libva 0.99.0, meanwhile open source libva bumped its API version to 1.0.0. Thus we have to blacklist only the MSDK's libva (0.99.0)
Created attachment 356441 [details] [review] build: check for libva-2.0 Check for libva-2.0 since libva's developers decided to increase the library's version number.
Created attachment 356660 [details] [review] build: blacklist only libva 0.99.0 Intel's MSDK uses libva 0.99.0, meanwhile open source libva bumped its API version to 1.0.0. Thus we have to blacklist only the MSDK's libva (0.99.0)
Created attachment 356661 [details] [review] build: check for libva-2.0 Check for libva-2.0 since libva's developers decided to increase the library's version number.
Created attachment 356662 [details] [review] libs: decoder: h264: libva 1.0 deprecated baseline libva 1.0 deprecated H.264 baseline profile and FMO support (commit b4f332b3).
Created attachment 356663 [details] [review] libs: utils: libva 1.0 changed the logging The logging mechanism in libva has changed it's functions signatures. This patch updates that for libva versions >= 1.0
Attachment 356660 [details] pushed as d8de185 - build: blacklist only libva 0.99.0 Attachment 356661 [details] pushed as 8f2eb70 - build: check for libva-2.0 Attachment 356662 [details] pushed as e0e0a47 - libs: decoder: h264: libva 1.0 deprecated baseline Attachment 356663 [details] pushed as 777bba4 - libs: utils: libva 1.0 changed the logging
libva developers have decided not to use the -2.0 name space, to avoid multiple library version installed. discussion here: https://github.com/01org/libva/issues/72
Created attachment 357799 [details] [review] libs: macro to get a renamed value in VA-API 1.0 In VA-API 1.0 the union bits in _VAEncMiscParameterBufferROI has renamed one member from roi_value_is_qp_delat to roi_value_is_qp_delta, which is the correct name. In order to keep back compatibility a macro has added to access this union member.
Created attachment 357800 [details] [review] Revert "build: check for libva-2.0" This reverts commit 8f2eb70803099d4b533ecc10fc259041d8714210.
Default compilation is failing with "deprecated declarations" warnings. We need a couple of things here: 1: Use RawData header for VAEncPackedHeader{H264, HEVC}_SEI if using VAAPI-1.0 2: deprecated declaration in va headers will generate the warnings anyway. Find a way to don't treat va specific deprecated declaration warnings as errors? Or just use -Wno-deprecated-declarations
(In reply to sreerenj from comment #17) > Default compilation is failing with "deprecated declarations" warnings. > > We need a couple of things here: > > 1: Use RawData header for VAEncPackedHeader{H264, HEVC}_SEI if using > VAAPI-1.0 > > 2: deprecated declaration in va headers will generate the warnings anyway. > Find a way to don't treat va specific deprecated declaration warnings as > errors? > Or just use -Wno-deprecated-declarations For 2: you could use GNU GCC diagnostic pragmas around the "header includes" (https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html) #pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wdeprecated-declarations" #include <va/va.h> #pragma GCC diagnostic pop ...not sure you'd want these diagnostics around where you "actually use" a deprecated thing, though.
Deprecated attributes don't generate compiler warnings until the thing marked as deprecated is "used". Unfortunately, some of the libva headers actually "use" some of the deprecated enums to assign values to other enums. This causes those compiler warnings (at the fault of libva) to propagate into all downstream projects that include those libva headers... even if the downstream projects do not use the deprecated things explicitly. IMO, libva should deal with this better and prevent its own usage of deprecated things from being exposed to other projects. Of course, projects that "use" the deprecated things should be warned as intended.
(In reply to U. Artie Eoff from comment #19) > Deprecated attributes don't generate compiler warnings until the thing > marked as deprecated is "used". Unfortunately, some of the libva headers > actually "use" some of the deprecated enums to assign values to other enums. > This causes those compiler warnings (at the fault of libva) to propagate > into all downstream projects that include those libva headers... even if the > downstream projects do not use the deprecated things explicitly. > > IMO, libva should deal with this better and prevent its own usage of > deprecated things from being exposed to other projects. > > Of course, projects that "use" the deprecated things should be warned as > intended. You are right, In this case libva should take care of the usage of "deprecated" variables.
Created attachment 358349 [details] [review] libs: guard deprecated symbols In libva-1.0 the H.264 baseline profile is deprecated (see commit e0e0a474), and VAEncPackedHeaderH264_SEI buffer type. This patch guards the H.264 baseline usage, and use VAEncPackedHeaderRawData instead of VAEncPackedHeaderH264_SEI in the case libva-1.0 is linked.
The last 3 patches compile clean for me with recent libva-2.0 (VA API 1.0) patch at https://github.com/01org/libva/pull/106 The only nit that I have is the usage of term "libva-1.0" in commit message for last patch. Technically it should be "libva-2.0" (or VA API 1.0).
Created attachment 358406 [details] [review] libs: macro to get a renamed value in VA-API 1.0 In VA-API 1.0 the union bits in VAEncMiscParameterBufferROI has renamed one member from roi_value_is_qp_delat to roi_value_is_qp_delta, which is the correct name. In order to keep back compatibility a macro has added to access this union member.
Created attachment 358407 [details] [review] Revert "build: check for libva-2.0" This reverts commit 8f2eb70803099d4b533ecc10fc259041d8714210.
Created attachment 358408 [details] [review] libs: guard deprecated symbols In VA-API 1.0 the H.264 baseline profile is deprecated. This patch guards the H.264 baseline usage. Consider this commit as a continuation of commit e0e0a474
Created attachment 358409 [details] [review] libs: encoder: h264: handle deprecated enum In VA-API 1.0 the enum VAEncPackedHeaderH264_SEI is deprecated, and instead VAEncPackedHeaderRawData should be used. This patch creates a compatibility symbol, VA_ENC_PACKED_HEADER_H264_SEI, to expose the used enum according the VA-API version.
Attachment 358406 [details] pushed as e8148ce - libs: macro to get a renamed value in VA-API 1.0 Attachment 358407 [details] pushed as 3c345e3 - Revert "build: check for libva-2.0" Attachment 358408 [details] pushed as 585628d - libs: guard deprecated symbols Attachment 358409 [details] pushed as b942f9e - libs: encoder: h264: handle deprecated enum