VA-API 1.0.0 (libva 2.0.0)

[xhaihao]

Hi all,

We are planning to bump the VA-API major version from 0.40.0 to 1.0.0. In the new version, we will

• fix errors in API/data structure definition, e.g. https://github.com/01org/libva/issues/32
• add new features, e.g. https://github.com/01org/libva/pull/69,
• deprecate some useless API/data structures, e.g. libva-tpi, libva-egl.
• provide other improvement, e.g. use portable type to define data structure.

I have created https://github.com/01org/libva/tree/v2.0-branch for the new version bumping. You are welcome if you have any comment / suggestion or patch to improve the api

Thanks
Haihao

[fhvwy]

Is there any plan with respect to loading of old and new drivers? It seems likely that libva1 and libva2 will need to coexist in distributions for a transitional period and the drivers will not be compatible, so there will have to be a way to install drivers for both at the same time. In particular, we currently load "foo_drv_video.so" - could we set a different suffix (like "foo_drv_va2.so", say), or maybe always use a different directory?

[chivakker]

Why would distributions need to use a newer driver with an older API? Normally they compile their rpm,deb with pkg-config and driver checks for the proper version of libva. Then the driver will be compiled and installed as usual.

The other scenario where an application uses an old VA-API to compile and makes no check on the driver available on the system will find that the new driver will not work. Then it is up to them to update their VA-API copy to comply with the new driver or just stay on a older version of the driver. They could package two versions of libva/intel-vaapi-driver if they want but it is up to them how they want to accomplish it.

[fhvwy]

Suppose you are a distribution and want to package both A, which uses libva1, and B, which uses libva2, such that they can be installed together and both work. You can't compile everything against libva2 because they aren't API compatible.

Now, you can straightforwardly make separate libva1 and libva2 packages (because they have different SONAMEs) and make A and B depend the appropriate one. But, with the current situation, only one of A and B could actually work because you only have one driver name and location to put the binary, and that will have to be either a libva1 driver or a libva2 driver, not both (though you could have a usable setup with, say, a libva1 Intel driver and a libva2 Mesa driver, I don't believe that is a useful case).

Without that compatibility, the obvious action for distributions is to just not package libva2 at all until both A and B are updated (if B has significant use then it will have to support both versions during the transition period anyway, so this is unlikely to be harmful to users in the short term). Given that possibility, I'm suggesting that libva2 should look for the binary in a different place or with a different name in order to allow both to coexist so that we do have a clear way forward for distributions.

[chivakker]

Let's take Ubuntu as an example. It installs the driver in a custom location /usr/lib/x86_64-linux-gnu/dri/ already. So, they can have /usr/lib/x86_64-linux-gnu/dri/A/ /usr/lib/x86_64-linux-gnu/dri/B/ and keep the same name for the driver.

Then when applications load libva1 or libva2, it will know which driver to load and they will not need to update their dlopen strings if they don't want to.

I'd prefer to work with the distributions in this way, instead of having the changes made in the driver. Is there other examples that we can refer to?

[sreerenjb]

Distributions should keep both versions of driver+libva for sure.

I am more inclined to the idea of having a different name for the new driver.so. This will avoid the possible confusion in using a non-ABI compatible package.

As an Eg: GStream project gone through the ABI breaking version change from 0.10 to 1.0, and it wasn't possible to ask every user, distros to switch to new one immediately. So they supported two coexisting versions gst-0.10 and gst-1.0 for a long time.

BTW, In case, If distribution only packages the new driver+libva which is neither API nor ABI compatible, it is going to break the middleware.

For eg: consider the use case of GStreamer-VA API,
The current GStreamer release is 1.12 which is not compatible with libva2.
Expected release date for next stable version is by the end of October, and it may take even more time.
If Distributions update the driver+libva without keeping the old version, there won't be GStreamer support for it until the next major release. It seems Ubunut-17.04 is still using gstreamer-1.10.x, not even updated to 1.12.x. So it takes, even more time for them to get a GStreamer version which can support libva2.

[fhvwy]

The aim here, as I see it, should be to get libva2 embedded in distributions reasonably quickly after release so that the clock can start ticking on abandoning libva1 entirely. We will have to support libva1 for a long time anyway for existing distributions (FFmpeg still works back to 1.2 because of this), but minimising that time can only be good for us in the long run.

Hence the suggested change, with intent that distributions don't need to consider compatibility in the transition and therefore no additional work is required and no other packages can block the upgrade from happening immediately (particularly thinking of the infrastructure ones like GStreamer and FFmpeg, which interact with a lot of other packages and are slower to upgrade as a result).

[xhaihao]

Besides the library, is it necessary to provide separate include files and pkg-config files for libva 2.0 based development? If yes, it would be better to change the package name as well.

[pengche1]

If we want to fix all coexist issues, I also prefer the solution like gstreamer. libva2.0 is totally new package and has nothing shared with libva1.0. But it needs framework to change the dependency to new package libva2.0. We need to figure how many efforts for framework or others and whether it is valuable to do this

[chivakker]

Following the ideas above I believe this could work better for co-existence. libva1 will remain as it is right now. (libva.so, libva-drm.so, i965_drv_video.so, etc).

Then I think it is better to create a new package libva-2.0 with libva-2.0.so, libva-drm-2.0.so, i965_drv_video-2.0.so.

As mentioned before this could help with the transition and having two installed libraries should not be a big of a burden.

[xhaihao]

I changed the libva library name to libva-2.0, please check the following PRs

libva: https://github.com/01org/libva/pull/81

libva-utils: intel/libva-utils#48

intel-vaapi-driver: intel/intel-vaapi-driver#216

[xhaihao]

Is it necessary to provide vainfo-2.0 etc in libva-utils?

[sebastinas]

As one of the Debian package maintainers, let me add that we prefer to maintain only one version of the library in our archive, i.e. we prefer to switch over all users of libva to libva 2.0 at once. Changing the pkg-config module name, which means that we have to patch all users of libva, is not optimal. While fixing all the types and structs definitions certainly requires a SONAME bump (at least that what #75 currently suggests), but only requires a rebuild of the reverse dependencies. Changing the pkg-config module name for this, incurs a lot more unnecessary work on us.

FWIW, the GStreamer situation is not something to strive for. It left a lot of programs broken.

[chivakker]

@sebastinas I agree with you that we could just switch over to libva-2.0. Would that also work with all versions of Ubuntu that are maintained? i.e. are you gonna go back and update the package for LTS as well?

[xhaihao]

@sebastinas , do other OSVs use the same way to update a library?

[sebastinas]

@chivakker Already released versions of Ubuntu usually do not perform library transitions. As Ubuntu follows Debian with respect to libva, the transition will only affect the current development release of Ubuntu (regardless of the actual implementation details).

@xhaihao As far as I am aware, all major distributions perform library transitions pretty much in the same way.

To give some idea of how we handle library transitions: we only want one version of any library per release. So if a library bumps its SONAME and requires a transition, we switch our current development suite to the new version of the library and rebuild all reverse dependencies to update the dependencies from the old to the new SONAME. Rebuilding those packages is mostly automated. Now if we have to patch the reverse dependencies because, this requires extra work to identify which rev deps need to be patched and prepare fixes for those packages. This extra work often enough causes delays in transitions. At current state of #75, we'd only be patching pkg-config file names, which is just cumbersome work on our side without any gain.

[xhaihao]

@sebastinas thanks for the explanation in detail. So you prefer to fix the broken packages when upgrading to libva2.0, right?

[xhaihao]

I rebased v2.0-branch against the latest branch, a forced update is required if you want to update your v2.0-branch, I am sorry for any inconvenience.

[xhaihao]

@uartie the patch to fix GCC 7.1 issue landed on v2.0-branch, could you help to add Fedora 26 to v2.0 build?

[xhaihao]

@sreerenjb @fhvwy @pengche1 Do you have any response to sebastinas's comment? I prefer to bump SONAME only if OSV prefer to maintain only one version of library in the archive.

[sebastinas]

@xhaihao I think there is still some misunderstanding. If you break the ABI, we require SONAME bumps. But we prefer SONAME bumps without breaking all the infrastructure around it, i.e. don't change pkg-config file names, move headers files around, etc.

[xhaihao]

@sebastinas currently the pgk-config file names were changed to libva-2.0 and libva-xxx-2.0 on v2.0-branch, so SONAME was changed as well. What I mean is to restore the pkg-config file names to libva and libva-xxx and bump SONAME only. We didn't move headers files around, however we changed some variable or type name, is this acceptable for you?

[chivakker]

@xhaihao given the feedback received, I'd prefer to bump up the version but not creating a new package name. I know we wanted to follow GStreamer approach but I believe we don't need to do exactly like them. The benefit as mentioned is that nothing on the build systems has to change and ABI gets fixed anyways. Please consider this option.

[xhaihao]

I will revert the commit which created a new package name, is there any comment?

[xhaihao]

The commit created a new pkg config file name was removed from v2.0-branch.

[uartie]

Currently libva 2.0.0 deprecates several enums...

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 (148b610). 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 2.0.0 should deal with this better and prevent its own usage of deprecated things from being exposed and propagated into other projects due to no fault of their own.

Of course, projects that "use" the deprecated things should be warned as intended.

[sreerenjb]

I agree with @uartie
From GStreamer side, even if avoid the usage of deprecated VA definitions, It still breaks the compilation.
Because gstreamer treat deprecated-variable-warning as error, and there is no way to avoid this unless we do some "GCC pragma stuffs" like this https://bugzilla.gnome.org/show_bug.cgi?id=784398#c18

[xhaihao]

Thanks @uartie @sreerenjb, I will fix libva not to use any deprecated enums.

[xhaihao]

Rebased v2.0-branch against the latest master branch, a forced update is needed when updating your local v2.0-branch, sorry for any inconvenience.

[sreerenjb]

Sorry I still don't get a clear picture of this :)
Again taking GStreamer as an example since it is one of the primary customers of libva, also there are many higher level applications(totem, transmageddon, clutter etc) using it.

I wonder how is it possible for a customer to get GStreamer/gstreamer-vaapi support If distros update libva to 2.0 (with out having a coexisting version of libva 1.x)?
Even the current stable release of GStreamer (1.12) won't be working with libva-2.0. The next stable version of GStreamer which can work with libva2-0 will be released only in November timeframe.

[sreerenjb]

@sebastinas I would like to know what you think about the issue I mentioned above from a package maintainer's viewpoint?

@fhvwy I guess you have the same issue with FFmpeg, right?

[sebastinas]

@sreerenjb As usual with library transitions, maintainers of the respective packages that are not compatible with the new version will be asked to cherry-pick patches from their upstreams (if available) or write them. For example, in preparation for the upnp 1.6 -> 1.8 transition, we wrote patches for vlc (https://git.videolan.org/?p=vlc/vlc-2.2.git;a=commitdiff;h=825dca78be3a81e2a1c5d04137aa01b1cb32dfd3) which were sent upstream, then applied the patch to the package (https://anonscm.debian.org/cgit/pkg-multimedia/vlc.git/tree/debian/patches/0014-upnp-Add-support-for-libupnp-1.8.patch) and we are now able to perform the transition. This is normal day-to-day business for package maintainers.

[sreerenjb]

@sebastinas when you say "maintainers of the respective packages", does it means the "package maintainer for a particular distribution"?
In GStreamer use case, we already have patches to support the libva-2.0 in GStreamer-vaapi git master. IIUC, the distribution package maintainer is supposed to cherry-pick the patches from gstreamer-vaapi git master, and make a custom release version of GStreamer-vaapi together with libva-2.0 package. ?

[xhaihao]

@sreerenjb @lizhong1008 Zhong verified FFmpeg can work with libva-2.0.

[Gnurou]

Hi, sorry for chiming in so late. I am working on multimedia for Chrome OS and would like to make sure the transition to libva 2.0 is as smooth as possible since it is a very important part for us.

libva 2.0 will break ABI compatibility between itself and its consumers, which is why its major version is increased. If that was all, we could stop there as both libva.so.1 and libva.so.2 can coexist and distros unwilling to distribute both can simply recompile their packages and call it a day.

But considering that the library's API will also change in a non-compatible manner, I can see several issues that cannot be avoided unless the package name is also updated.

Consider a system on which libva 2 is installed, where we want to compile a program relying on libva 1.x. In its configure script, it will check for libva >= 1.x and will be satisfied by the result. When the compiler is called, it will find all the va/va_*.h files it looks up, only to notice that some structure or function prototype does not look like expected and throw a cryptic error at the user.

The only proper way that I know to handle this cleanly is to have a different namespace for both versions:

libva 1.x:
/usr/lib/libva.so.1
/usr/include/va
/usr/lib/pkgconfig/libva.pc

libva 2.x:
/usr/lib/libva.so.2
/usr/include/va2
/usr/lib/pkgconfig/libva2.pc

In other words, an ABI incompatibility can be handled by a major library version upgrade, but an API incompatibility requires a new namespace for package and headers lookup. Doing so, both versions can be installed simultaneously and unambiguously, and a package looking for libva >= 1.x will return an error during the configure step as it should. And projects like Chromium that may want to use both will be able to do so.

Major libraries (e.g. gtk) already work that way and that's for a good reason. Unless we have total control over the consumers of libva (and we don't), you cannot expect them all to upgrade in a timely manner (or even to upgrade at all).

I am not sure whether the ABI between libva and its drivers is also broken, but if that's the case then these also need to use a different namespace. If the API also changes, then drivers will meet the same problem as above.

So yeah, to the extent that I understand the situation we want libva 2.0 to be unambiguously separate from libva 1.

[chivakker]

@Gnurou so on your "distributiton" (ChromeOS) you'd need and will be carrying both libraries on all platforms or certain platforms? I think ebuilds have the ability to check for version numbers. i.e. if ebuild checks for exactly version 1.8.x then it will break at configure time, on the other side if the library gets updated ebuild can check for exactly version 2.x. Would it be better to carry only one library instead of two?

[Gnurou]

Please don't look at it in terms of whether this will work for your current users. You never exactly knows who your users are, and this is how we let things like ABI incompatibilities slip into the 1.x series. It may look like at first sight that Chrome OS can accommodate keeping headers and pkgconfig files in the same place, but if the design is not sound, it will break in unexpected places.

In my previous comment I have given a scenario where keeping things as they are would clearly break - and it's not like it is a crazy scenario, this is just how any current user of libva detects it. I have also given a proposal to avoid this. Well it's not my proposal, it is what every other library does whenever their API changes, for very good reasons. Can you see a practical reason why libva should do differently? If not, why not go the safe way and avoid issues down the road?

Regarding the specific case of Chrome OS, if we ever want to have both libva 1 and 2 on the sysroot (and I suspect that we will for at least some transition time), then we also want to host both versions of the headers, and I would rather not resort to PKGBUILD hackery in order to achieve that.

Note that I don't propose that the package or library name should be renamed to libva2. It is just that include and pkgconfig files should go under a different namespace. Distros are then free to decide how they name their libva 2.0 packages: libva2 if they still have programs requiring the 1.x ABI, or simply libva if they can upgrade them all in lockstep. Things would not get more complicated for anyone.

[xhaihao]

@Gnurou I understand your concern. However I think most users install libva from distribution. Once distribution moves libva and all vaapi based packages to libva2, most user won't experience the compatibility issue. It is easy for distribution to move to libva2 with the current pkg-config name, otherwise distribution has to patch each vaapi based package if using different namespace for libva2

[Gnurou]

@xhaihao

most user won't experience the compatibility issue

Shouldn't the fact that "some" users will experience the compatibility issue be a concern?

It is easy for distribution to move to libva2 with the current pkg-config name, otherwise distribution has to patch each vaapi based package if using different namespace for libva2

This is not true.

libva 2.0 breaks API compatibility, meaning that unless libva 1.0 can be shipped alongside 2.0, distros will have to patch packages relying on VA-API to support the new API regardless of where the include files are located.

The difference with using a different namespace for libva 2.0 is that this leaves distros with a choice about how to handle the situation:

1. Only ship libva 2 and patch every libva 1 user to be compatible with it. Potentially a lot of packages to patch, and error-prone.
2. Allow libva 1 and 2 to coexist on the system, not having to worry about individual packages compatibility, until all packages have upgraded to 2.x and libva1 can be retired.

IIUC @sebastinas' comment was under the assumption that the API would not change, in which case a simple rebuild of dependent packages would be enough to make the switch. But that's not what is happening here.

[chivakker]

@sebastinas Initially I understood that to avoid Libva-2.0 naming, you can work with applications to adapt to changes. Later, and as mentioned by @Gnurou, it is not clear if that was under the assumption that only ABI will be updated. Am I understanding this correctly?

I am not expecting that everyone will agree with my next argument, but I want to try to converge to a solution that will comply with most of the reasonable requirements

In changing both ABI and API there's never a clear winner. In my opinion this is an opportunity
to correct errors made in the past and come with a clean ABI API that people can start using at their will. If in doubt I think applications/distributions and other libva users should stay on 1.8.3 if the transition results painful. Then maybe analyze if jumping to a newer version makes sense. People in this project can help to solve problems as they occur.

I know that I cannot forecast how applications and distributions will use this library but I can understand how it might fail for them. So far, it will fail at compile time if using one or more of the typos on structure members. Also deprecated members will show warnings during compilation. I am expecting that this will hit the majority of users.

For users that are not calling any of the changes then their applications will continue compiling but no error will be seen unless broken ABI results on weird behavior. I would not like to add a per version size check on all driver functions using the modified structures. These users might be the most affected in my opinion if they never realize about compiling against the new library. Within this category there will be those that carry a copy of the API headers and use them to compile their libraries. That would mean that they don't check for version when calling VaInit. I believe the number of cases is very less and can possible be treated case by case.

As I am not completely opposed to go back to the idea of having two library names, I'd prefer to avoid reworks on applications that have already transitioned to this scheme and that are testing with Libya-2.0 in its current form. That includes me.

[Gnurou]

@chivakker I don't quite understand what your position is from your latest comment, could you clarify?

I'd prefer to avoid reworks on applications that have already transitioned to this scheme and that are testing with Libya-2.0 in its current form. That includes me.

Given that libva 2.0 is not released yet, I see that rework as perfectly legitimate, especially if it allows users to avoid all the troubles you listed above.

[chivakker]

@Gnurou per the break down on why users might be affected, I want to stay with one library. But as said I am not terribly opposed to have two libraries and assume the rework needed. I am expecting others to weigh in.

[sebastinas]

@Gnurou No, my argument is not under the assumption that the API does not change. Even if the API changes we prefer to not change the pkg-config name -- libva-2.0 is not a completely different library and has not the size of GTK+ or Qt that makes co-existing a necessity. And if a reverse dependency only use parts of the API that do not change, we do not have to patch.

Let's look at some numbers: In Debian we currently have 17 reverse dependencies of libva. If libva-2.0 would be releases today, only 7 of them fail to build against current libva-2.0. That makes 10 packages which can use libva-2.0 without any changes after a simple rebuild. From those 7 failing, three of them are tightly coupled to libva (intel-vaapi-driver, libva-utils and libyami) and those we'd update in sync with libva anyway. The other 4 packages are gstreamer-vaapi, kodi, mpv and ring. At least gstreamer-vaapi is supposed to have a fix already and the remaining three we'd have to patch.

So to transition from libva-2.0 when keeping the pkg-config name untouched, we only have to touch three packages. If the pkg-config name changes, we suddenly have to touch more than 10 packages just to update the pkg-config name. We clearly prefer to only have to touch 3 packages.

To sum it up: we will only care one libva version in our development release and we try to switch as soon as possible. You make our lives easier if we do not have to patch packages just for pkg-config name changes.

Note that if you want to go down the rabbit hole of co-existing libva versions, one needs to also consider the case when both libraries are loaded in the same process (would one need to introduce symbol versioning in both libva versions to avoid clashes of symbols present in both libraries?), and many other issues that might arise in this case.

[Gnurou]

@chivakker

per the break down on why users might be affected, I want to stay with one library. But as said I am not terribly opposed to have two libraries and assume the rework needed.

Well you will have two libraries (libva.so.1 and libva.so.2) whichever way you go, but unless you choose different package names you won't allow them to be installed concurrently. A major library version upgrade is precisely to allow two incompatible versions of a library to coexist on the same system, but you won't let your users take advantage of that.

@sebastinas

So to transition from libva-2.0 when keeping the pkg-config name untouched, we only have to touch three packages. If the pkg-config name changes, we suddenly have to touch more than 10 packages just to update the pkg-config name. We clearly prefer to only have to touch 3 packages.

How about having to touch 0 packages? I don't quite understand the issue you have with having libva and libva2 package names. You can deprecate libva 1 after all reverse dependencies have upgraded to 2.x, and even rename libva2 to libva if you like. At the end of the day, you will end up with exactly one package, without even having to patch anyone and fixing unexpected runtime incompatibilities introduced by libva 2 (we often had these upon minor updates, let alone a major one!).

Of course that is your call as far as Debian in concerned. But do you know for sure that Fedora, Arch, Suse, Gentoo, and everyone else plans on following that direction too?

My point is that unexpected compile-time errors are a big red flag indicating that something is wrong with the upgrade path design. What we believe we can do in practice to get away with it is irrelevant (and not reliable). It's just broken.

Anyway, I won't argue this any further if you don't agree. We can and will work this around in Chromium OS, just trying to spare unneeded trouble to everyone.

[sebastinas]

@Gnurou

How about having to touch 0 packages? I don't quite understand the issue you have with having libva and libva2 package names. You can deprecate libva 1 after all reverse dependencies have upgraded to 2.x, and even rename libva2 to libva if you like.

Huch? Why would I want touch every build script to use pkg-config libva-2.0 to port it to libva-2.0 first and then after that was done go back and change everything to pkg-config libva again? This does not make sense. I think we are a talking about different things.

[Gnurou]

@sebastinas

Huch? Why would I want touch every build script to use pkg-config libva-2.0 to port it to libva-2.0 first and then after that was done go back and change everything to pkg-config libva again? This does not make sense. I think we are a talking about different things.

We are indeed. What I suggested is just that you let libva users decide thenselves when and how to update to 2.0. When they do that they will request libva2's pkgconfig (instead of the current libva), and you will have no extra step to take (apart maybe from upping libva's requirement in their control file) when that happens. Just like when a package switches from GTK 2 to 3.

[xhaihao]

We will maintain only one version of libva:

• If both libva1 and libva2 coexist, we will have to maintain two versions of libva for a long time because we don't know when user will switch to the new library.
• Per the number provided by @sebastinas, only a few applications will be patched when using the current libva2 because libva2 is not a completely different library from libva1.
• Per our experience on libyami and gstream-vaapi, it is easy to patch an application to use the current libva2 if this application is broken when switching to libva2.

You can still use libva1 but we won't support libva1 with new features and new platforms any more. I'm sorry for any inconvenience caused to you.

[xhaihao]

We will merge libva-2.0 branch to master branch soon (https://lists.01.org/pipermail/intel-vaapi-media/2017-September/000068.html), besides the compatibility concern, do you have any other concerns?

[Gnurou]

I will simply reiterate our concern regarding compatibility: libva1 unexpected ABI breakages have been a nightmare for Chromium OS to manage. We expect that to stop with 2.0 and will blacklist any version that introduces backward-incompatible changes to the ABI or API from now on.

[xhaihao]

I apologize for compatibility breaks in libva1 and we will do our best to avoid compatibility breaks in libva2. You are also welcome to help review the new APIs @Gnurou

[Gnurou]

Yes, we will try to be more active in that respect. Thanks!

[xhaihao]

I merged v2.0-branch to master branch, please move your development to master. I will use v2.0-branch for stable release.

[fhvwy]

Two things which I think should be done before releasing libva2:

• Add the new surface export mechanism (initially Add a more flexible interface for import/export of DRM objects #85, now Add a more flexible interface for import/export of DRM objects #125). This is needed by both the Mesa driver (for any useful export at all) and the Intel driver for (for additional metadata / modifiers to use with KMS / scanout). It would help if someone from the Intel / gstreamer side could make sure that they are happy with how it is defined.
• Add some way for drivers to send log messages to the API user to inform them about problems - I have proposed Add a route for drivers to send messages to the API message callbacks #128 to add this, but I'm not particularly attached to the method, other ideas welcome. As more APIs are added to libva, this becomes more important - even now, use of the Intel driver is barely possible to debug at all without reference to the source code. Since it is a driver ABI change, ideally this happens on the major version bump to avoid compatibility problems later.

Then, if possible:

• Improve the colour management situation. Currently VPP offers only a control for the colour space while neglecting all other colour-related controls - this causes problems in all conversions, particularly between RGB and YUV where neither side is well-defined. I have proposed RFC: Add more complete colour properties for use in VPP #127 to match all colour information in other standards (as H.264/H.265: range, chroma subsampling location, colour primaries, transfer characteristics, matrix coefficients), comments there are welcome. This is less important to me than the other two, but it does cause confusion for users when colours are incorrect (and is becoming much more obvious with HDR).

[geki-yaba]

Well, just a stupid thought, but it is possible to generate .pc files with a given postfix; default to be empty. So upstream and debian is happy and others are free to have libva*${postfix}.pc. This and includedir flag to configure; to separate headers actually. All happy.

Example can be found here:
https://tecnocode.co.uk/2014/12/09/a-checklist-for-writing-pkg-config-files/

Code snippet:

# Output files
# Rename the template .pc file to include the API version on configure
AC_CONFIG_FILES([
pkgconfig/libva$API_POSTFIX.pc:pkgconfig/libva.pc.in
…
],[],
[API_POSTFIX='$API_POSTFIX'])
AC_OUTPUT

[rossburton]

Just pointing out that ${postfix} isn't a good idea because anyone who uses it has then generated a fork of libva that unmodified software won't work on, so that's only introducing problems.