Allow Display to be used by multiple threads

[cadubentzen]

Closes #14

As mentioned in the issue, libva mentions the following:

All VAAPI functions implemented in libva are thread-safe. For any VAAPI function that requires the implementation of a backend (e.g. hardware driver), the backend must ensure that its implementation is also thread-safe. If the backend implementation of a VAAPI function is not thread-safe then this should be considered as a bug against the backend implementation.

It is assumed that none of the VAAPI functions will be called from signal handlers.

Thread-safety in this context means that when VAAPI is being called by multiple concurrent threads, it will not crash or hang the OS, and VAAPI internal data structures will not be corrupted. When multiple threads are operating on the same VAAPI objects, it is the application's responsibility to synchronize these operations in order to generate the expected results. For example, using a single VAContext from multiple threads may generate unexpected results.

I've been testing with this patch in an application that shares the Display in multiple threads, and this has worked well.

[rosetta-jpn]

Thanks for the patch. I will assess this patch with the team and update here.

[cadubentzen]

Thanks for the patch. I will assess this patch with the team and update here.

Thanks! I also have the corresponding change in cros-codecs to work with this update, btw.

[rosetta-jpn]

Thanks! I also have the corresponding change in cros-codecs to work with this update, btw.

The team is positive in this change.
However, the team is internally changing cros-codecs code. The gap is huge in GitHub ToT.
I will merge this for sure but probably early next year. Is it okay for you?

[cadubentzen]

I will merge this for sure but probably early next year. Is it okay for you?

Sure. We're using a downstream version of this package with the change already applied. Just having this upstream at some point will help us reduce the delta.

However, the team is internally changing cros-codecs code. The gap is huge in GitHub ToT.

When will the GitHub ToT have the latest changes? I have a series of patches to upstream to cros-codecs, but having this gap certainly makes it difficult for external contributions.

[rosetta-jpn]

When will the GitHub ToT have the latest changes? I have a series of patches to upstream to cros-codecs, but having this gap certainly makes it difficult for external contributions.

We use to develop cros-codecs in ASOP.
https://android.googlesource.com/platform/system/cros-codecs/
However, the recent AOSP freeze decision which happened this April forces us to develop the code in the Android internal tree.
The internal tree code will be released in AOSP (public) quaterly.
I fully agree that this makes external developers contribution difficult.

I am thinking about setting a bot which syncs GitHub with the internal code or manually.
But I don't have time for either way.

If you send PRs in cros-codecs GitHub repo, I can asset the change and consider if they can be merged.

Thanks.