chromium: hardware video acceleration with VA-API

svito · 2019-08-26 20:50:27

I'm on wayland if it means anything.

Wayland support is not enabled in chromium-vaapi package. I'll add this to the wiki so people like you see it.

Also you should use paste service instead of making wall of text.

Last edited by svito (2019-08-26 20:51:30)

yabk · 2019-08-26 20:56:36

svito wrote:

I'm on wayland if it means anything.
Wayland support is not enabled in chromium-vaapi package. I'll add this to the wiki so people like you see it.

It runs over Xwayland, does that make a difference?

I saw a few users above mentioning wayland and it seems like my issues are similar to those of CarbonChauvinist so I thought I should mention it. Sorry if it was confusing.

Last edited by yabk (2019-08-26 21:12:27)

svito · 2019-08-26 21:14:14

It runs over Xwayland, does that make a difference?

On Wayland it does not work because Wayland is not enabled in the package.

On XWayland it does not work because DRI3 is not supported by libva/intel_drivers, whoever did patches disappeared.

I saw a few users above mentioning wayland and it seems like my issues are similar to those of CarbonChauvinist so I tought I should mention it. Sorry if it was confusing.

I have no idea, I could not follow what CarbonChauvinist is doing.

liewkj · 2019-08-27 02:57:30

@sooqua @yabk
I have already flagged that chromium-vaapi and chromium-vaapi-bin include an inappropriate vaapi-fix.patch that breaks proper VA-API implementation conforming to VA-API >= 2.0.0. If you want to get chromium-vaapi work for Intel hardware, then you need to re-compile the package by removing vaapi-fix.patch. For Intel hardware using i965 driver, you will also need to stay with Xorg session for VA-API to work. If you run Chromium on Wayland session where Chromium is working through Xwayland, then VA-API will not work. I don't have data on more recent Intel hardware that use iHD drivers. There is a whitepaper that says Intel supports DRI3 with the new driver, if that is true, then VA-API will work under Wayland native display.

I don't know when the AUR maintainers would acknowledge this and remove the faulty vaapi-fix.patch that only favors NVIDIA binary blobs which never supports VA-API to begin with and the community-driven libva-vdpau-driver has long been abandoned from further updates to keep up with VA-API >=2.0.0.

CarbonChauvinist · 2019-08-27 13:34:04

svito wrote:

I have no idea, I could not follow what CarbonChauvinist is doing.

At the time I wrote those series of posts @maximbaz had just added the VA-API fix (vaapi-fix.patch) which caused HW decode to stop working for me in a Wayland session. Before the patch was applied to the chromium-vaapi{,-bin} packages I was able to get HW decode in Wayland with the "--use-gl=egl" flag added to ~/.config/chromium-flags.conf. After the patch HW decode did not work at all in Wayland no matter the flags passed.

I was, at the time, rebuilding the package without the patch, and as long as I had the "--use-gl=egl" flag in ~/.config/chromium-flags.conf file I could still get HW decode in a Wayland session.

I've since moved back to default chromium, because for me the use case for hw decoded video in Chromium in Wayland was not worth the extra time and effort compiling the package just to remove the patch (I'd normally run the -bin package to avoid having to compile).

@liewkj seems to be referencing the exact issue I had in his post though I was using iHD driver. I believe this quote gets at the crux of the issue from my perspective (I can't speak to the veracity of all his claims, just know that when that patch was added, for me in Wayland, HW decode stopped working, removing it allowed me to have HW decode in Wayland again as long as I had "--use-gl=egl" in ~/.config/chromium-flags.conf).

liewkj wrote:

I don't know when the AUR maintainers would acknowledge this and remove the faulty vaapi-fix.patch that only favors NVIDIA binary blobs which never supports VA-API to begin with and the community-driven libva-vdpau-driver has long been abandoned from further updates to keep up with VA-API >=2.0.0.

Last edited by CarbonChauvinist (2019-08-27 13:45:41)

akarshanbiswas · 2019-08-27 14:49:57

liewkj wrote:

@sooqua @yabk
I have already flagged that chromium-vaapi and chromium-vaapi-bin include an inappropriate vaapi-fix.patch that breaks proper VA-API implementation conforming to VA-API >= 2.0.0. If you want to get chromium-vaapi work for Intel hardware, then you need to re-compile the package by removing vaapi-fix.patch. For Intel hardware using i965 driver, you will also need to stay with Xorg session for VA-API to work. If you run Chromium on Wayland session where Chromium is working through Xwayland, then VA-API will not work. I don't have data on more recent Intel hardware that use iHD drivers. There is a whitepaper that says Intel supports DRI3 with the new driver, if that is true, then VA-API will work under Wayland native display.
I don't know when the AUR maintainers would acknowledge this and remove the faulty vaapi-fix.patch that only favors NVIDIA binary blobs which never supports VA-API to begin with and the community-driven libva-vdpau-driver has long been abandoned from further updates to keep up with VA-API >=2.0.0.

@liewkj You need DRI3 support in Intel driver, Or switch to Xorg. Intel drivers are too buggy! Removing the patch will make vaapi to stop working on few intel GPUs; I think I'll redo the patch to enable egl (which is faulty) and enable VPP. For Nvidia users can switch to Nouveau or may rant on their forums to create a vaapi --> nvdec bridge.. Hmm that's what I'm going to do.

I was getting lot of requests from Nvidia users and I can say that even with this "hack" some nvidia drivers are not working.

For chromium-ozone, last time I tried >~70s

libgtkui is broken
mutter doesn't support zwp_dmabuf_linux protocol to run a multi process wayland client
shell integration is broken
vaapi is broken as well(need GPU process to be running).

I guess I will try to build once again to see how everything is working. But I confirm that UI isn't fixed yet

Last edited by akarshanbiswas (2019-08-27 14:52:32)

liewkj · 2019-08-28 02:06:46

akarshanbiswas wrote:

You need DRI3 support in Intel driver, Or switch to Xorg. Intel drivers are too buggy! Removing the patch will make vaapi to stop working on few intel GPUs; I think I'll redo the patch to enable egl (which is faulty) and enable VPP. For Nvidia users can switch to Nouveau or may rant on their forums to create a vaapi --> nvdec bridge.. Hmm that's what I'm going to do.

I did specially build i965 driver and libva with DRI3 patch, and that made VA-API work for gstreamer-vaapi and mpv-vaapi under Wayland session. However, Chromium-vaapi simply rendered video into total black screen. This was exactly the same issue the maintainer of i965 driver/libva was getting before the DRI3 patch submitter disappeared and abandoned his patchset. Someone pointed out that there were other issues on Wayland compositor with respect to refresh rate and buffers synchronization, but I could not track them down.

I don't believe there is any patch to the Chromium source required other than the "use_vaapi=true" build flag to get VA-API accelerated video decoding. I strongly believe that Google/Chromium developers had already done enough due diligence in the implementation to conform to the specification (from Intel). Mesa/Gallium/st_va VA-API implementation follows the same specification. The outlier is NVIDIA binary blobs, and they don't care. I don't know how Fedora or Ubuntu PPA deals with this situation, but I do come across blogs/articles on Chromium hardware video acceleration that, for that moment, it only worked for Intel iGPU.

CarbonChauvinist wrote:

I've since moved back to default chromium, because for me the use case for hw decoded video in Chromium in Wayland was not worth the extra time and effort compiling the package just to remove the patch (I'd normally run the -bin package to avoid having to compile).

I can't help but have to concur with this. In fact, the default Chromium, both FFMpegVideoDecoder and VpxVideoDecoder do make use of GPU 3D hardware for some video offloading. The difference with and without VA-API is only about 10% more CPU utilization for 720p and 1080p, typical YouTube or streaming video use cases. Perhaps, 4K video would make sense for VA-API but I do not have the data and never stream 4K video over internet. VA-API would make sense for low-end laptops and ultrabooks, for eg. Sandybridge Celeron 847 (40%/20%) and AMD C60 (80%/40%) at 720p H.264 decoding.

akarshanbiswas · 2019-08-28 05:14:43

liewkj wrote:

I strongly believe that Google/Chromium developers had already done enough due diligence in the implementation to conform to the specification (from Intel).

Upstream doesn't support vaapi on Linux at all. They only test devices and drivers which ships official ChromeOS. Few "good" people are there who only fix build errors for enable_vaapi=true for Linux that's it.

liewkj · 2019-08-28 20:15:10

akarshanbiswas wrote:

Upstream doesn't support vaapi on Linux at all. They only test devices and drivers which ships official ChromeOS. Few "good" people are there who only fix build errors for enable_vaapi=true for Linux that's it.

Well, I can hardly see that being true for now. Yes, I have seen the enable_vaapi patch for past Chromium a few years ago during version 71-72, and it was extremely involved. Nowadays, I would say things have changed and this is clearly evident by looking at PKGBUILD of AUR chromium-vaapi. By removing the faulty vaapi-fix.patch, none of the source files are touched and the build simply adds "use_vaapi=true". Everything else is as pristine as upstream.

What the upstream doesn't support is to have vaapi enabled by default on Linux, and I do see that their arguments are quite valid. However, for whatever the past reasoning was, the upstream has now made it easy to enable vaapi for Linux just by rebuilding with the appropriate build flag.

Well, hacking chromium-vaapi to work for NVIDIA binary blobs is a totally different story.

liewkj · 2019-08-29 04:02:00

Here's the clean patch for Chromium that makes everyone happy. No #if/#endif, no blatantly forcing buffer_allocation_mode_ and perform VA driver detection using vendor string for VDPAU backend driver to bypass VPP. Hardware accelerated video decoding was verified with GK208B with nvidia-390xx and Ryzen APU with radeonsi from Mesa/Gallium/st_va. There is really nothing to fix for VA-API drivers that conform to VA-API >= 2.0.0 such as Intel and Mesa/Gallium/st_va drivers, so this is really just fix for NVIDIA binary blobs VDPAU backend, if this is what holding the AUR maintainers from removing the existing faulty vaapi-fix.patch.

Hopefully, we can have the chromium-vaapi and chromium-vaapi-bin AUR maintainers switching to this patch for future builds.

diff -ru ../_tmp/chromium-76.0.3809.132/media/gpu/vaapi/vaapi_video_decode_accelerator.cc ./src/chromium-76.0.3809.132/media/gpu/vaapi/vaapi_video_decode_accelerator.cc
--- ../_tmp/chromium-76.0.3809.132/media/gpu/vaapi/vaapi_video_decode_accelerator.cc    2019-08-26 21:36:12.734301800 -0700
+++ ./src/chromium-76.0.3809.132/media/gpu/vaapi/vaapi_video_decode_accelerator.cc      2019-08-28 19:47:31.899571700 -0700
@@ -633,6 +633,7 @@
   // |vpp_vaapi_wrapper_| for VaapiPicture to DownloadFromSurface() the VA's
   // internal decoded frame.
   if (buffer_allocation_mode_ != BufferAllocationMode::kNone &&
+      buffer_allocation_mode_ != BufferAllocationMode::kWrapVdpau &&
       !vpp_vaapi_wrapper_) {
     vpp_vaapi_wrapper_ = VaapiWrapper::Create(
         VaapiWrapper::kVideoProcess, VAProfileNone,
@@ -650,7 +651,8 @@
     // only used as a copy destination. Therefore, the VaapiWrapper used and
     // owned by |picture| is |vpp_vaapi_wrapper_|.
     std::unique_ptr<VaapiPicture> picture = vaapi_picture_factory_->Create(
-        (buffer_allocation_mode_ == BufferAllocationMode::kNone)
+        ((buffer_allocation_mode_ == BufferAllocationMode::kNone) ||
+         (buffer_allocation_mode_ == BufferAllocationMode::kWrapVdpau))
             ? vaapi_wrapper_
             : vpp_vaapi_wrapper_,
         make_context_current_cb_, bind_image_cb_, buffers[i]);
@@ -1065,6 +1067,14 @@

 VaapiVideoDecodeAccelerator::BufferAllocationMode
 VaapiVideoDecodeAccelerator::DecideBufferAllocationMode() {
+  // NVIDIA blobs use VDPAU
+  if (base::StartsWith(VaapiWrapper::GetVendorStringForTesting(),
+              "Splitted-Desktop Systems VDPAU",
+              base::CompareCase::SENSITIVE)) {
+    LOG(INFO) << "VA-API driver on VDPAU backend";
+    return BufferAllocationMode::kWrapVdpau;
+  }
+
   // TODO(crbug.com/912295): Enable a better BufferAllocationMode for IMPORT
   // |output_mode_| as well.
   if (output_mode_ == VideoDecodeAccelerator::Config::OutputMode::IMPORT)
diff -ru ../_tmp/chromium-76.0.3809.132/media/gpu/vaapi/vaapi_video_decode_accelerator.h ./src/chromium-76.0.3809.132/media/gpu/vaapi/vaapi_video_decode_accelerator.h
--- ../_tmp/chromium-76.0.3809.132/media/gpu/vaapi/vaapi_video_decode_accelerator.h     2019-08-26 21:36:12.739126900 -0700
+++ ./src/chromium-76.0.3809.132/media/gpu/vaapi/vaapi_video_decode_accelerator.h       2019-08-28 17:58:38.955872900 -0700
@@ -204,6 +204,7 @@
     // Using |client_|s provided PictureBuffers and as many internally
     // allocated.
     kNormal,
+    kWrapVdpau,
   };

   // Decides the concrete buffer allocation mode, depending on the hardware

Last edited by liewkj (2019-08-29 11:25:58)

akarshanbiswas · 2019-09-12 13:09:46

liewkj wrote:

Here's the clean patch for Chromium that makes everyone happy. No #if/#endif, no blatantly forcing buffer_allocation_mode_ and perform VA driver detection using vendor string for VDPAU backend driver to bypass VPP. Hardware accelerated video decoding was verified with GK208B with nvidia-390xx and Ryzen APU with radeonsi from Mesa/Gallium/st_va. There is really nothing to fix for VA-API drivers that conform to VA-API >= 2.0.0 such as Intel and Mesa/Gallium/st_va drivers, so this is really just fix for NVIDIA binary blobs VDPAU backend, if this is what holding the AUR maintainers from removing the existing faulty vaapi-fix.patch.

Hopefully, we can have the chromium-vaapi and chromium-vaapi-bin AUR maintainers switching to this patch for future builds.

diff -ru ../_tmp/chromium-76.0.3809.132/media/gpu/vaapi/vaapi_video_decode_accelerator.cc ./src/chromium-76.0.3809.132/media/gpu/vaapi/vaapi_video_decode_accelerator.cc
--- ../_tmp/chromium-76.0.3809.132/media/gpu/vaapi/vaapi_video_decode_accelerator.cc    2019-08-26 21:36:12.734301800 -0700
+++ ./src/chromium-76.0.3809.132/media/gpu/vaapi/vaapi_video_decode_accelerator.cc      2019-08-28 19:47:31.899571700 -0700
@@ -633,6 +633,7 @@
   // |vpp_vaapi_wrapper_| for VaapiPicture to DownloadFromSurface() the VA's
   // internal decoded frame.
   if (buffer_allocation_mode_ != BufferAllocationMode::kNone &&
+      buffer_allocation_mode_ != BufferAllocationMode::kWrapVdpau &&
       !vpp_vaapi_wrapper_) {
     vpp_vaapi_wrapper_ = VaapiWrapper::Create(
         VaapiWrapper::kVideoProcess, VAProfileNone,
@@ -650,7 +651,8 @@
     // only used as a copy destination. Therefore, the VaapiWrapper used and
     // owned by |picture| is |vpp_vaapi_wrapper_|.
     std::unique_ptr<VaapiPicture> picture = vaapi_picture_factory_->Create(
-        (buffer_allocation_mode_ == BufferAllocationMode::kNone)
+        ((buffer_allocation_mode_ == BufferAllocationMode::kNone) ||
+         (buffer_allocation_mode_ == BufferAllocationMode::kWrapVdpau))
             ? vaapi_wrapper_
             : vpp_vaapi_wrapper_,
         make_context_current_cb_, bind_image_cb_, buffers[i]);
@@ -1065,6 +1067,14 @@

 VaapiVideoDecodeAccelerator::BufferAllocationMode
 VaapiVideoDecodeAccelerator::DecideBufferAllocationMode() {
+  // NVIDIA blobs use VDPAU
+  if (base::StartsWith(VaapiWrapper::GetVendorStringForTesting(),
+              "Splitted-Desktop Systems VDPAU",
+              base::CompareCase::SENSITIVE)) {
+    LOG(INFO) << "VA-API driver on VDPAU backend";
+    return BufferAllocationMode::kWrapVdpau;
+  }
+
   // TODO(crbug.com/912295): Enable a better BufferAllocationMode for IMPORT
   // |output_mode_| as well.
   if (output_mode_ == VideoDecodeAccelerator::Config::OutputMode::IMPORT)
diff -ru ../_tmp/chromium-76.0.3809.132/media/gpu/vaapi/vaapi_video_decode_accelerator.h ./src/chromium-76.0.3809.132/media/gpu/vaapi/vaapi_video_decode_accelerator.h
--- ../_tmp/chromium-76.0.3809.132/media/gpu/vaapi/vaapi_video_decode_accelerator.h     2019-08-26 21:36:12.739126900 -0700
+++ ./src/chromium-76.0.3809.132/media/gpu/vaapi/vaapi_video_decode_accelerator.h       2019-08-28 17:58:38.955872900 -0700
@@ -204,6 +204,7 @@
     // Using |client_|s provided PictureBuffers and as many internally
     // allocated.
     kNormal,
+    kWrapVdpau,
   };

   // Decides the concrete buffer allocation mode, depending on the hardware

It's not because of VPP, It's because the patch switched to vaGetDisplayDRM() instead of vaGetDisplayEGL() when it fails to vaGetDisplayX11() and hence chromium launched with --use-gl=egl failed.
I have taken those bits blindly from here which was shared in this same arch forum thread in order to fix the regression with few Intel GPUs(also Nvidia). Since I now know where the problem is, I am going to remove it anyway.

Also, thanks for that patch!

Last edited by akarshanbiswas (2019-09-12 13:16:27)

liewkj · 2019-09-13 05:04:40

akarshanbiswas wrote:

It's not because of VPP, It's because the patch switched to vaGetDisplayDRM() instead of vaGetDisplayEGL() when it fails to vaGetDisplayX11() and hence chromium launched with --use-gl=egl failed.
I have taken those bits blindly from here which was shared in this same arch forum thread in order to fix the regression with few Intel GPUs(also Nvidia). Since I now know where the problem is, I am going to remove it anyway.
Also, thanks for that patch!

I think it is important to retain the VPP as what Google has implemented. Chromebooks are predominately Intel and Intel defines the VA-API specification. NVIDIA binary blobs didn't play along well, what working now is just a hack and no one knows if it will continue to work in future. Abruptly bypassing VPP only works for certain Intel GPU and perhaps specific video formats. I know about the Ubuntu PPA for Chromium-VAAPI, and they had the wrong patch, too. Things could have worked before since VPP is only available for libva >= 2.0.0. I think they should be informed of this simplified patch, too, that works out more universally.

Mesa-19.1.6 has the VA-API fix for Nouveau, I verified the fix on GK208B. So with this simplified patch, I have tested MESA/Gallium/st_va drivers (r600, radeonsi, nouveau), Intel i965 and nvidia-390xx, all are good. I am looking forward to the maintainers of chromium-vaapi and chromium-vaapi-bin to use the simplified patch instead so that VA-API video decoding for Linux would move ahead with the right direction.

Last edited by liewkj (2019-09-13 05:07:41)

akarshanbiswas · 2019-09-13 07:58:50

@maximbaz Can you please try the patch which liewkj shared ? I want to know if that fixes the intel regression which you and others are having.

liewkj · 2019-09-20 23:25:02

@maximbaz @akarshanbiswas
I am running chromium-vaapi 77.0.3865.90 I built myself from extra/chromium with the simplified patch on fully updated Arch.

linux 5.3.arch1-1
mesa 19.1.7-1
gnome-shell 1:3.34.0+94+g3d86e6e79-1
mutter 3.34.0+6+gab7af2d0c-1
gdm 3.34.0-2

Both nouveau and nvidia-390xx work fine for H.264 on GK208B.
SNB/Celeron using Intel i965 works fine for H.264.
Ryzen APU using MESA radeonsi works fine for H.264 and VP9.

MESA based st_va drivers such as nouveau and radeonsi work under GNOME/Wayland.

I am looking forward to the next chromium-vaapi-bin to be built with the simplified patch and hopefully more test results would come in, especially for Intel iHD driver on Intel Skylake and Kabylake CPUs. When the test results gathered sufficient positive outcomes with variety of hardware, perhaps extra/chromium can once again be compiled with VA-API support.

justkdng · 2019-10-11 23:15:15

liewkj wrote:

Here's the clean patch for Chromium that makes everyone happy. No #if/#endif, no blatantly forcing buffer_allocation_mode_ and perform VA driver detection using vendor string for VDPAU backend driver to bypass VPP. Hardware accelerated video decoding was verified with GK208B with nvidia-390xx and Ryzen APU with radeonsi from Mesa/Gallium/st_va. There is really nothing to fix for VA-API drivers that conform to VA-API >= 2.0.0 such as Intel and Mesa/Gallium/st_va drivers, so this is really just fix for NVIDIA binary blobs VDPAU backend, if this is what holding the AUR maintainers from removing the existing faulty vaapi-fix.patch.

Hopefully, we can have the chromium-vaapi and chromium-vaapi-bin AUR maintainers switching to this patch for future builds.

diff -ru ../_tmp/chromium-76.0.3809.132/media/gpu/vaapi/vaapi_video_decode_accelerator.cc ./src/chromium-76.0.3809.132/media/gpu/vaapi/vaapi_video_decode_accelerator.cc
--- ../_tmp/chromium-76.0.3809.132/media/gpu/vaapi/vaapi_video_decode_accelerator.cc    2019-08-26 21:36:12.734301800 -0700
+++ ./src/chromium-76.0.3809.132/media/gpu/vaapi/vaapi_video_decode_accelerator.cc      2019-08-28 19:47:31.899571700 -0700
@@ -633,6 +633,7 @@
   // |vpp_vaapi_wrapper_| for VaapiPicture to DownloadFromSurface() the VA's
   // internal decoded frame.
   if (buffer_allocation_mode_ != BufferAllocationMode::kNone &&
+      buffer_allocation_mode_ != BufferAllocationMode::kWrapVdpau &&
       !vpp_vaapi_wrapper_) {
     vpp_vaapi_wrapper_ = VaapiWrapper::Create(
         VaapiWrapper::kVideoProcess, VAProfileNone,
@@ -650,7 +651,8 @@
     // only used as a copy destination. Therefore, the VaapiWrapper used and
     // owned by |picture| is |vpp_vaapi_wrapper_|.
     std::unique_ptr<VaapiPicture> picture = vaapi_picture_factory_->Create(
-        (buffer_allocation_mode_ == BufferAllocationMode::kNone)
+        ((buffer_allocation_mode_ == BufferAllocationMode::kNone) ||
+         (buffer_allocation_mode_ == BufferAllocationMode::kWrapVdpau))
             ? vaapi_wrapper_
             : vpp_vaapi_wrapper_,
         make_context_current_cb_, bind_image_cb_, buffers[i]);
@@ -1065,6 +1067,14 @@

 VaapiVideoDecodeAccelerator::BufferAllocationMode
 VaapiVideoDecodeAccelerator::DecideBufferAllocationMode() {
+  // NVIDIA blobs use VDPAU
+  if (base::StartsWith(VaapiWrapper::GetVendorStringForTesting(),
+              "Splitted-Desktop Systems VDPAU",
+              base::CompareCase::SENSITIVE)) {
+    LOG(INFO) << "VA-API driver on VDPAU backend";
+    return BufferAllocationMode::kWrapVdpau;
+  }
+
   // TODO(crbug.com/912295): Enable a better BufferAllocationMode for IMPORT
   // |output_mode_| as well.
   if (output_mode_ == VideoDecodeAccelerator::Config::OutputMode::IMPORT)
diff -ru ../_tmp/chromium-76.0.3809.132/media/gpu/vaapi/vaapi_video_decode_accelerator.h ./src/chromium-76.0.3809.132/media/gpu/vaapi/vaapi_video_decode_accelerator.h
--- ../_tmp/chromium-76.0.3809.132/media/gpu/vaapi/vaapi_video_decode_accelerator.h     2019-08-26 21:36:12.739126900 -0700
+++ ./src/chromium-76.0.3809.132/media/gpu/vaapi/vaapi_video_decode_accelerator.h       2019-08-28 17:58:38.955872900 -0700
@@ -204,6 +204,7 @@
     // Using |client_|s provided PictureBuffers and as many internally
     // allocated.
     kNormal,
+    kWrapVdpau,
   };

   // Decides the concrete buffer allocation mode, depending on the hardware

Interesting patch @liewkj , gonna test this on ungoogled-chromium.
Funnily enough, I just finished compiling 77.0.3865.120 with the old vaapi patch, good thing I havent released it yet.
Thanks.

maximbaz · 2019-10-12 11:11:47

Sorry for the absence, I was not aware of this discussion and I haven't received a single email notification from the forum... (thanks to @liewkj for pinging me on AUR!)

I'm gonna compile chromium with the patch above, if everything is fine I'll push to `chromium-vaapi` in a couple of hours.

bsdice · 2019-10-12 11:17:13

Can you test libva-intel-driver as well as intel-media-driver? I tried out intel-media-driver yesterday using /etc/environment and LIBVA_DRIVER_NAME=iHD and the browser would stop playback after only a couple of seconds of Youtube, I think I only tried a seeks and window resizing and the noise screen with error message would show. Not sure if the seek bug is still present, was running the very latest of updates as of yesterday.

maximbaz · 2019-10-12 12:58:02

I've tested the proposed patch, with both `libva-intel-driver` and `intel-media-driver` VP9 is not working on my integrated Intel GPU. So it's definitely not a better fix. Please have a look if I missed something:

- code: https://github.com/maximbaz/pkgbuilds/c … 7432836f90
- compiled pkg: https://pkgbuild.com/~maximbaz/repo/chr … pkg.tar.xz

justkdng · 2019-10-12 13:01:31

Can confirm that the new patch doesn't work with neither libva-intel-driver nor intel-media-driver. Tested with my i5 7200U, kaby lake btw. It's this error all over again: https://github.com/intel/intel-vaapi-driver/issues/456
Just in case:
- PKGBUILD: https://github.com/jstkdng/ungoogled-ch … archlinux/
- compiled pkg: https://repo.vin.ovh/arch/x86_64/ungoog … pkg.tar.xz
In the meantime, I'll add the old version back to my repo, you should downgrade @bsdice until the new patch works
Edit: It works on my 3400G, haven't tested with nvidia.

Last edited by justkdng (2019-10-12 13:16:51)

akarshanbiswas · 2019-10-12 14:43:42

maximbaz wrote:

I've tested the proposed patch, with both `libva-intel-driver` and `intel-media-driver` VP9 is not working on my integrated Intel GPU. So it's definitely not a better fix. Please have a look if I missed something:
- code: https://github.com/maximbaz/pkgbuilds/c … 7432836f90
- compiled pkg: https://pkgbuild.com/~maximbaz/repo/chr … pkg.tar.xz

As expected. Intel driver hangs when BAM is reduced much. Can you add this patch along with that patch to check whether it is working or not?
I am using this on Fedora(RPMFusion). No complaints yet. (I disabled Nvidia support)

From 2fb5ffb6de4752a404e1ec406b31880288f1cc82 Mon Sep 17 00:00:00 2001
From: Akarshan Biswas <akarshanbiswas@fedoraproject.org>
Date: Fri, 20 Sep 2019 19:04:07 +0530
Subject: [PATCH] Use Normal BAM on Linux to workaround some intel driver
 issues

---
 media/gpu/vaapi/vaapi_video_decode_accelerator.cc | 9 +++++++++
 media/gpu/vaapi/vaapi_wrapper.cc                  | 2 +-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/media/gpu/vaapi/vaapi_video_decode_accelerator.cc b/media/gpu/vaapi/vaapi_video_decode_accelerator.cc
index 95df4498b..d7f39be58 100644
--- a/media/gpu/vaapi/vaapi_video_decode_accelerator.cc
+++ b/media/gpu/vaapi/vaapi_video_decode_accelerator.cc
@@ -66,6 +66,7 @@ void ReportToUMA(VAVDADecoderFailure failure) {
 // Returns true if the CPU is an Intel Gemini Lake or later (including Kaby
 // Lake) Cpu platform id's are referenced from the following file in kernel
 // source arch/x86/include/asm/intel-family.h
+#if defined(OS_ANDROID) || defined(OS_CHROMEOS)
 bool IsGeminiLakeOrLater() {
   constexpr int kPentiumAndLaterFamily = 0x06;
   constexpr int kGeminiLakeModelId = 0x7A;
@@ -75,6 +76,7 @@ bool IsGeminiLakeOrLater() {
       cpuid.model() >= kGeminiLakeModelId;
   return is_geminilake_or_later;
 }
+#endif 
 
 }  // namespace
 
@@ -1077,6 +1079,10 @@ VaapiVideoDecodeAccelerator::GetSupportedProfiles() {
 
 VaapiVideoDecodeAccelerator::BufferAllocationMode
 VaapiVideoDecodeAccelerator::DecideBufferAllocationMode() {
+#if defined(OS_LINUX) && !defined(OS_ANDROID) && !defined(OS_CHROMEOS)
+	return BufferAllocationMode::kNormal;
+#else
+
   // TODO(crbug.com/912295): Enable a better BufferAllocationMode for IMPORT
   // |output_mode_| as well.
   if (output_mode_ == VideoDecodeAccelerator::Config::OutputMode::IMPORT)
@@ -1089,6 +1095,7 @@ VaapiVideoDecodeAccelerator::DecideBufferAllocationMode() {
   // depends on the bitstream and sometimes it's not enough to cover the amount
   // of frames needed by the client pipeline (see b/133733739).
   // TODO(crbug.com/911754): Enable for VP9 Profile 2.
+ 
   if (IsGeminiLakeOrLater() &&
       (profile_ == VP9PROFILE_PROFILE0 || profile_ == VP8PROFILE_ANY)) {
     // Add one to the reference frames for the one being currently egressed, and
@@ -1098,6 +1105,7 @@ VaapiVideoDecodeAccelerator::DecideBufferAllocationMode() {
       num_extra_pics_ = 3;
     return BufferAllocationMode::kNone;
   }
+ 
 
   // If we're here, we have to use the Vpp unit and allocate buffers for
   // |decoder_|; usually we'd have to allocate the |decoder_|s
@@ -1112,6 +1120,7 @@ VaapiVideoDecodeAccelerator::DecideBufferAllocationMode() {
     return BufferAllocationMode::kReduced;
 
   return BufferAllocationMode::kSuperReduced;
+#endif 
 }
 
 bool VaapiVideoDecodeAccelerator::IsBufferAllocationModeReducedOrSuperReduced()
diff --git a/media/gpu/vaapi/vaapi_wrapper.cc b/media/gpu/vaapi/vaapi_wrapper.cc
index 7df60e273..d291d3ad0 100644
--- a/media/gpu/vaapi/vaapi_wrapper.cc
+++ b/media/gpu/vaapi/vaapi_wrapper.cc
@@ -397,7 +397,7 @@ bool VADisplayState::InitializeOnce() {
   int major_version, minor_version;
   VAStatus va_res = vaInitialize(va_display_, &major_version, &minor_version);
   if (va_res != VA_STATUS_SUCCESS) {
-    LOG(ERROR) << "vaInitialize failed: " << vaErrorStr(va_res);
+    LOG(ERROR) << "vaInitialize failed!(ignore if using Wayland desktop environment, refer:https://github.com/akarshanbiswas/chromium-vaapi/issues/7)  " << vaErrorStr(va_res);
     return false;
   }
 
-- 
2.21.0

maximbaz · 2019-10-12 17:24:42

The patch doesn't apply because both of them modify the beginning of `VaapiVideoDecodeAccelerator::DecideBufferAllocationMode()` - to make sure I don't accidentally screw up these tests by manually fixing patches, if that's not too much trouble could you please send me either the patch that can apply on top of @liewkj's one, or perhaps just a single combined patch?

If that's simpler, feel free to just send a PR here: https://github.com/maximbaz/pkgbuilds/t … -new-patch

In the meantime, could you please clarify for me the purpose of these patches? The one shared by @liewkj is supposed to fix Nvidia support, and the one shared by you is for Intel, is that correct?

liewkj · 2019-10-12 17:40:28

@maximbaz @justkdng
Thanks for the feedback. Did you guys check out Intel GPU on Wayland or X11 session? How about H.264 video playback? This is an extremely important detail for looking into VA-API.

libva-intel-driver works for me for Sandybridge and Haswell generations of HD Graphics for H.264 video playback on X11 session. My patch has been working very well for all MESA based VA drivers (r600, nouveau, radeonsi). VP9 works on my Ryzen 2500U.

I will see if I can get my hands on Skylake generation HD Graphics to check it out.

maximbaz · 2019-10-12 17:54:12

X11, H.264 works well with both drivers, but I believe H.264 works well even if I don't apply any patches anyway.

By the way, I have i7-7820HQ, which is Kaby Lake gen I believe.

liewkj · 2019-10-12 17:58:18

It puzzled me how on earth would Intel GPUs ever need any patch for proper VA-API support. They are the dominant player in the ChromeOS market and the code should have been tailored for their hardware to begin with. Are we sure that the old patch worked out well for Intel GPU? Someone had already reported earlier that it didn't on his Intel GPU, even for H.264, and I think he is using Skylake generation.

liewkj · 2019-10-12 18:06:11

maximbaz wrote:

X11, H.264 works well with both drivers, but I believe H.264 works well even if I don't apply any patches anyway.

Ok, that makes perfect sense for Intel GPU.
And, were you able to get VP9 working with the old patch? I remember someone said the old patch didn't work, too. Can you use youtube-dl to download the video locally and play it through mpv using VA-API?

$ mpv --hwdec=vaapi -vo vaapi /path/to/VP9

Arch Linux

#126 2019-08-26 20:50:27

Re: chromium: hardware video acceleration with VA-API

#127 2019-08-26 20:56:36

Re: chromium: hardware video acceleration with VA-API

#128 2019-08-26 21:14:14

Re: chromium: hardware video acceleration with VA-API

#129 2019-08-27 02:57:30

Re: chromium: hardware video acceleration with VA-API

#130 2019-08-27 13:34:04

Re: chromium: hardware video acceleration with VA-API

#131 2019-08-27 14:49:57

Re: chromium: hardware video acceleration with VA-API

#132 2019-08-28 02:06:46

Re: chromium: hardware video acceleration with VA-API

#133 2019-08-28 05:14:43

Re: chromium: hardware video acceleration with VA-API

#134 2019-08-28 20:15:10

Re: chromium: hardware video acceleration with VA-API

#135 2019-08-29 04:02:00

Re: chromium: hardware video acceleration with VA-API

#136 2019-09-12 13:09:46

Re: chromium: hardware video acceleration with VA-API

#137 2019-09-13 05:04:40

Re: chromium: hardware video acceleration with VA-API

#138 2019-09-13 07:58:50

Re: chromium: hardware video acceleration with VA-API

#139 2019-09-20 23:25:02

Re: chromium: hardware video acceleration with VA-API

#140 2019-10-11 23:15:15

Re: chromium: hardware video acceleration with VA-API

#141 2019-10-12 11:11:47

Re: chromium: hardware video acceleration with VA-API

#142 2019-10-12 11:17:13

Re: chromium: hardware video acceleration with VA-API

#143 2019-10-12 12:58:02

Re: chromium: hardware video acceleration with VA-API

#144 2019-10-12 13:01:31

Re: chromium: hardware video acceleration with VA-API

#145 2019-10-12 14:43:42

Re: chromium: hardware video acceleration with VA-API

#146 2019-10-12 17:24:42

Re: chromium: hardware video acceleration with VA-API

#147 2019-10-12 17:40:28

Re: chromium: hardware video acceleration with VA-API

#148 2019-10-12 17:54:12

Re: chromium: hardware video acceleration with VA-API

#149 2019-10-12 17:58:18

Re: chromium: hardware video acceleration with VA-API

#150 2019-10-12 18:06:11

Re: chromium: hardware video acceleration with VA-API

Board footer