> I still don't understand why we can't postpone the VAAPI_Initialize() call? This is not explained by the comment.

`VAAPI_Initialize()` can be postponed after sandboxing, but the driver library should be loaded before sandbox, that is how upstream does (dlopen the hard coded driver in PreSandbox stage). 

As I explained, if we want to enable libva for linux in general, hard code of driver patch won't work. For eg, I checked Tizen and Ubuntu (32bit) , libva driver on different path. 

With my try and testing, calling some va call will do load the driver, VAAPI_Initialize() is best one to me. You could use `vainfo` to check.

> What the ChromeOS code is doing is merely pre-loading shared libraries for later usage and your code does the same. The fact that it is using a hardcode path is an optimization.
I do not look at it is a optimization, as I said above, if upstream want to support libva in general linux. Hard code won't work at all. While for upstream, ChromeOS is the only platform and they control where the libva driver is shipped, so hard code is no problem.

> Why you could not just use the code here? `content/common/gpu/media/vaapi_wrapper.cc`

The code in `content/common/gpu/media/vaapi_wrapper.cc` are post sandboxing, please check https://codereview.chromium.org/169403009/. If we want to PreSandboxing thing, we either add the PreSandbox interface back and implement in `vaapi_wrapper.c` or totolay do in this file(`content/common/sandbox_linux/bpf_gpu_policy_linux.cc`). I choose the latter one for simple.