Arch Linux

liewkj

Member

Registered: 2019-07-08

Posts: 210

Re: chromium: hardware video acceleration with VA-API

I think I passed that with the fix below, still building though.

--- orig/chromium-81.0.4044.92/media/gpu/vaapi/vaapi_picture_tfp.cc	2020-04-02 21:11:34.000000000 -0700
+++ src/chromium-81.0.4044.92/media/gpu/vaapi/vaapi_picture_tfp.cc	2020-04-08 23:30:40.870513860 -0700
@@ -57,7 +57,7 @@
   if (make_context_current_cb_ && !make_context_current_cb_.Run())
     return false;
 
-  glx_image_ = new gl::GLImageGLX(size_, GL_RGB);
+  glx_image_ = new gl::GLImageGLX(size_, gfx::BufferFormat::BGRX_8888);
   if (!glx_image_->Initialize(x_pixmap_)) {
     // x_pixmap_ will be freed in the destructor.
     DLOG(ERROR) << "Failed creating a GLX Pixmap for TFP";

One more. Hopefully, this will be the last one.

--- orig/chromium-81.0.4044.92/media/mojo/services/gpu_mojo_media_client.cc	2020-04-02 21:11:34.000000000 -0700
+++ ./src/chromium-81.0.4044.92/media/mojo/services/gpu_mojo_media_client.cc	2020-04-09 00:44:58.871366432 -0700
@@ -158,6 +158,7 @@
       *d3d11_supported_configs_;
 
 #elif BUILDFLAG(USE_CHROMEOS_MEDIA_ACCELERATION)
+#if defined(OS_CHROMEOS)
   if (base::FeatureList::IsEnabled(kChromeosVideoDecoder)) {
     if (!cros_supported_configs_) {
       cros_supported_configs_ =
@@ -167,6 +168,7 @@
         *cros_supported_configs_;
     return supported_config_map;
   }
+#endif  //defined(OS_CHROMEOS)
 #endif
 
   auto& default_configs =

Last edited by liewkj (2020-04-10 09:12:51)

Preycon

Member

From: México, D.F.

Registered: 2009-02-14

Posts: 51

Re: chromium: hardware video acceleration with VA-API

Hi, i have problems with chromium-vaapi in the last 2 versions(80.0.3987.163 and the one before this). The issue is that on youtube videos higher than 720p or videos higher than 720p and 60 fps lag. I can cofirm that hardware decoding is working by inspecting chrome://media-internals and all is properly setup(since i've been using it for long without issues). When that happens if i insepct nerd statistics on youtube i notice that many frames get simply dropped at those resolutions and the cpu goes skyrocket to 100% on many cores. My laptop is t495s amd ryzen 3700u pro with the 5.6.2 kernel. I also tried reverting the kernel but the issue looks like is the chromium build. Has anyone run into these issues aswell?

Yeah, I have the same problem, fresh arch install, so no mesa downgrade.

Ryzen 2500u with vega graphics.

liewkj

Member

Registered: 2019-07-08

Posts: 210

Re: chromium: hardware video acceleration with VA-API

Hi, i have problems with chromium-vaapi in the last 2 versions(80.0.3987.163 and the one before this). The issue is that on youtube videos higher than 720p or videos higher than 720p and 60 fps lag. I can cofirm that hardware decoding is working by inspecting chrome://media-internals and all is properly setup(since i've been using it for long without issues). When that happens if i insepct nerd statistics on youtube i notice that many frames get simply dropped at those resolutions and the cpu goes skyrocket to 100% on many cores. My laptop is t495s amd ryzen 3700u pro with the 5.6.2 kernel. I also tried reverting the kernel but the issue looks like is the chromium build. Has anyone run into these issues aswell?

Yeah, I have the same problem, fresh arch install, so no mesa downgrade.

Ryzen 2500u with vega graphics.

I would be rather taken aback for such regression on AMD Ryzen APUs. Unfortunately, my kid now possesses the Ryzen 2500U APU system that used to be my daily driver. Thinking of getting myself another Ryzen APU with current discount sales of 3000 series or paid up for the latest 4000 series APU.

If you run Chromium on from the console, did you observe any logs that were related to VA-API? Make sure you *DO NOT* use "--use-gl=egl".

justkdng

Member

From: 日本

Registered: 2019-10-08

Posts: 46

Re: chromium: hardware video acceleration with VA-API

@liewkj

Thanks for the patches, testing them right now. There is this patch as well that was added to chromium-vaapi some releases ago but it no longer is patching correctly. Do you know about it?

From 4a04af6bbd5b1a55e2e1a7c22f13f8571c2dd7ed Mon Sep 17 00:00:00 2001
From: Julien Isorce <julien.isorce@chromium.org>
Date: Fri, 24 Jan 2020 00:30:33 +0000
Subject: [PATCH] Reland "Call PreSandboxStartup after GL initialization in GpuInit"

This is a reland of d17c53b341adcfc9e2626162536a08c9f3e24017

Original change's description:
> Call PreSandboxStartup after GL initialization in GpuInit
> 
> Fixes "vaInitialize failed: unknown libva error"
> on Wayland with LIBVA_DRIVER_NAME=i965
> 
> VaapiWrapper relies on the GL implementation to decide
> which display to use. If the GL implementation is none,
> then VaapiWrapper is likely to do the wrong guess resulting
> in the above error.
> 
> Bug: 1041229
> Change-Id: I1255a032a5e14b3aaffe3026a886de7e6d9ff0d7
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2011640
> Reviewed-by: Maggie Chen <magchen@chromium.org>
> Reviewed-by: Kenneth Russell <kbr@chromium.org>
> Commit-Queue: Julien Isorce <julien.isorce@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#733847}

Bug: 1041229
Change-Id: I8e268596a1e2a1b3da7d7e75b8943accc85dd2d7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2013806
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Maggie Chen <magchen@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Commit-Queue: Julien Isorce <julien.isorce@chromium.org>
Cr-Commit-Position: refs/heads/master@{#734746}
---

diff --git a/gpu/ipc/service/gpu_init.cc b/gpu/ipc/service/gpu_init.cc
index 04883fc..4e63f7a 100644
--- a/gpu/ipc/service/gpu_init.cc
+++ b/gpu/ipc/service/gpu_init.cc
@@ -221,10 +221,16 @@
   delayed_watchdog_enable = true;
 #endif
 
+#if defined(OS_LINUX)
   // PreSandbox is mainly for resource handling and not related to the GPU
   // driver, it doesn't need the GPU watchdog. The loadLibrary may take long
   // time that killing and restarting the GPU process will not help.
-  sandbox_helper_->PreSandboxStartup();
+  if (gpu_preferences_.gpu_sandbox_start_early) {
+    // The sandbox will be started earlier than usual (i.e. before GL) so
+    // execute the pre-sandbox steps now.
+    sandbox_helper_->PreSandboxStartup();
+  }
+#endif
 
   // Start the GPU watchdog only after anything that is expected to be time
   // consuming has completed, otherwise the process is liable to be aborted.
@@ -320,6 +326,23 @@
     }
   }
 
+  // The ContentSandboxHelper is currently the only one implementation of
+  // gpu::GpuSandboxHelper and it has no dependency. Except on Linux where
+  // VaapiWrapper checks the GL implementation to determine which display
+  // to use. So call PreSandboxStartup after GL initialization. But make
+  // sure the watchdog is paused as loadLibrary may take a long time and
+  // restarting the GPU process will not help.
+  if (!attempted_startsandbox) {
+    if (watchdog_thread_)
+      watchdog_thread_->PauseWatchdog();
+
+    // The sandbox is not started yet.
+    sandbox_helper_->PreSandboxStartup();
+
+    if (watchdog_thread_)
+      watchdog_thread_->ResumeWatchdog();
+  }
+
   bool gl_disabled = gl::GetGLImplementation() == gl::kGLImplementationDisabled;
 
   // Compute passthrough decoder status before ComputeGpuFeatureInfo below.

@preycon

That makes no sense as 160 and 163 were just security related releases. Only culprit could be the recent mesa updates imo.

---

GPG key: 3DEA 6251 3C80 3538 3A24  5A12 E578 6B42 E8E5 D565

liewkj

Member

Registered: 2019-07-08

Posts: 210

Re: chromium: hardware video acceleration with VA-API

There is this patch as well that was added to chromium-vaapi some releases ago but it no longer is patching correctly. Do you know about it?

That's the wayland fix, we don't need it for M81 now, it is already there.

My build was done, unfortunately VA-API is busted for M81 and required further analysis of what changed. This is going to take some time.

[98046:98046:0409/050544.688168:ERROR:vaapi_video_decode_accelerator.cc(758)] Failed to allocate memory for a VaapiPicture
[98498:14:0409/050544.688406:ERROR:batching_media_log.cc(38)] MediaEvent: {"error":"VDA Error 4"}
[98046:98046:0409/050627.264013:ERROR:vaapi_video_decode_accelerator.cc(758)] Failed to allocate memory for a VaapiPicture
[98498:14:0409/050627.264273:ERROR:batching_media_log.cc(38)] MediaEvent: {"error":"VDA Error 4"}

Both NVIDIA and Intel showed the same error. Xorg/Wayland does not matter. But for Intel, "--use-gl=egl" is also busted, that means Wayland busted for i965 VA driver. This is a pretty bad regression, unfortunately.

CarbonChauvinist

Member

Registered: 2012-06-16

Posts: 413

Website

Re: chromium: hardware video acceleration with VA-API

@preycon

That makes no sense as 160 and 163 were just security related releases. Only culprit could be the recent mesa updates imo.

Agreed, might try reverting back to i965 mesa driver as iris is now the default? Though this may not work either per @liewkj's post above.

As for me, I've decided to move over to Firefox (using nightly) as I can reliably have it working with Wayland and also VAAPI enabled hw accel (though it seems less performant than Chromium? (based only on the comparisons of percentages shown using intel_gpu_top))

---

"the wind-blown way, wanna win? don't play"

Preycon

Member

From: México, D.F.

Registered: 2009-02-14

Posts: 51

Re: chromium: hardware video acceleration with VA-API

I would be rather taken aback for such regression on AMD Ryzen APUs. Unfortunately, my kid now possesses the Ryzen 2500U APU system that used to be my daily driver. Thinking of getting myself another Ryzen APU with current discount sales of 3000 series or paid up for the latest 4000 series APU.

If you run Chromium on from the console, did you observe any logs that were related to VA-API? Make sure you *DO NOT* use "--use-gl=egl".

I'm using Xorg, not Wayland, so I think this is a mesa problem.

justkdng

Member

From: 日本

Registered: 2019-10-08

Posts: 46

Re: chromium: hardware video acceleration with VA-API

@liewkj

my build finished some time ago and vaapi is also broken, using the iHD vaapi driver here

---

GPG key: 3DEA 6251 3C80 3538 3A24  5A12 E578 6B42 E8E5 D565

digitalone

Member

Registered: 2011-08-19

Posts: 350

Re: chromium: hardware video acceleration with VA-API

Hi, i have problems with chromium-vaapi in the last 2 versions(80.0.3987.163 and the one before this). The issue is that on youtube videos higher than 720p or videos higher than 720p and 60 fps lag. I can cofirm that hardware decoding is working by inspecting chrome://media-internals and all is properly setup(since i've been using it for long without issues). When that happens if i insepct nerd statistics on youtube i notice that many frames get simply dropped at those resolutions and the cpu goes skyrocket to 100% on many cores. My laptop is t495s amd ryzen 3700u pro with the 5.6.2 kernel. I also tried reverting the kernel but the issue looks like is the chromium build. Has anyone run into these issues aswell?

Try --use-gl=egl flag.

The lag is happening to me without that flag, but not with it. Anyway I'm using an older Radeon card.

liewkj

Member

Registered: 2019-07-08

Posts: 210

Re: chromium: hardware video acceleration with VA-API

I am sorry, my bad.
GL_RGB should actually map to gfx::BufferFormat::BGRX_8888

I have corrected the patch from above, and yeah VA-API now works!

liewkj

Member

Registered: 2019-07-08

Posts: 210

Re: chromium: hardware video acceleration with VA-API

Flag "--use-gl=egl" is broken and it is broken on the official build without use_vaapi=true, too. So this means VA-API on Wayland is totally busted for Intel GPUs for both i965 and iHD VA drivers.

digitalone

Member

Registered: 2011-08-19

Posts: 350

Re: chromium: hardware video acceleration with VA-API

Flag "--use-gl=egl" is broken and it is broken on the official build without use_vaapi=true, too. So this means VA-API on Wayland is totally busted for Intel GPUs for both i965 and iHD VA drivers.

I use radeon driver, updated to linux 5.6 and new chromium-vaapi version. Now I see that --use-gl=egl isn't working and removing the flag I have lag on 1080p60 videos inside the browser.

Tried also to downgrade chromium-vaapi, the flag is working, but the lag on 1080p60 is showing the same.

Maybe I can try to downgrade the kernel, but I don't want.

youtube-dl, streamlink and mpv is da way.

Last edited by digitalone (2020-04-10 20:10:13)

liewkj

Member

Registered: 2019-07-08

Posts: 210

Re: chromium: hardware video acceleration with VA-API

Upstream Chromium bug confirmed.
https://bugs.chromium.org/p/chromium/is … id=1069772

Hopefully, next release for Chromium will resolve the "--use-gl=egl" bug and have video decode acceleration restored for Wayland.

Preycon

Member

From: México, D.F.

Registered: 2009-02-14

Posts: 51

Re: chromium: hardware video acceleration with VA-API

I would be rather taken aback for such regression on AMD Ryzen APUs. Unfortunately, my kid now possesses the Ryzen 2500U APU system that used to be my daily driver. Thinking of getting myself another Ryzen APU with current discount sales of 3000 series or paid up for the latest 4000 series APU.

If you run Chromium on from the console, did you observe any logs that were related to VA-API? Make sure you *DO NOT* use "--use-gl=egl".

Yes, it is a serious regression for Vega, I don't have any problem on my desktop with an RX590, don't know if the culprit is the kernel, mesa, libva or xf86-video-amdgpu, I'm getting frustrated by this hardware, 'cause again neither suspend or hibernate works too.

Last edited by Preycon (2020-04-20 01:43:03)

dimischiavone

Member

From: Turin

Registered: 2019-09-13

Posts: 20

Re: chromium: hardware video acceleration with VA-API

Yes, it is a serious regression for Vega, I don't have any problem on my desktop with an RX590, don't know if the culprit is the kernel, mesa, libva or xf86-video-amdgpu, I'm getting frustrated by this hardware, 'cause again neither suspend or hibernate works too.

Yeah it is really frustrating for me too. Since the last 3 versions of the kernel and the last 2 upgrades to mesa and chromium, hardware accelleration works for some videos (h264) and not for others. Since today (kernel 5.6.6) i'm having lag even with youtube videos at 720p 60 fps.
If i run chromium from the terminal and try to open this video i get this errors:

[4621:4621:0422/123755.220019:ERROR:browser_switcher_service.cc(238)] XXX Init()
[4645:4645:0422/123755.384725:ERROR:sandbox_linux.cc(374)] InitializeSandbox() called with multiple threads in process gpu-process.
mesa: for the --simplifycfg-sink-common option: may only occur zero or one times!
mesa: for the --global-isel-abort option: may only occur zero or one times!
mesa: for the --amdgpu-atomic-optimizations option: may only occur zero or one times!

By inspecting "statistics for nerds" in youtube video it shows that many frames get dropped whenever the video lags and blocks
For the hibernate issue i can confirm that too and it's really frustrating because i always have 8 virtual desktops setup and i usually never shutdown so i need to reset all my workflow each time these things don't work.

Last edited by dimischiavone (2020-04-22 13:46:58)

liewkj

Member

Registered: 2019-07-08

Posts: 210

Re: chromium: hardware video acceleration with VA-API

I finally found the issue with VA-API on Wayland, especially for Intel GPUs that have to take the EGL code path for VA-API to work in Wayland session. My previous workaround was to downgrade xorg-server-xwayland to 1.19.7. That is no longer required and it works fine with the official xorg-server-xwayland package from Arch repo, at the time of writing 1.20.8-2. It turned out that upstream xwayland was just fine, Chromium simply required a reliable platform methods for predicting v-sync. When not taking the EGL code path. the GLX extension GLX_OML_sync_control provides the GetVSync() and GetMscRate() function for Chromium codes that try to predict v-sync. This is the GLX code path and it is the default for Linux build.

When taking the EGL code path, Google defined EGL_CHROMIUM_sync_control provides the equivalent for GetVsync() but no GetMscRate(). The later is provided through ANGLE which is a cross-platform conformant Open GL ES implementation by Google in its own extension EGL_ANGLE_sync_control_rate. So when GetMscRate() returned false, the codes fallback to an approximate calculation to predict v-sync.

In chromium-81.0.4044.138/ui/gl/sync_control_vsync_provider.cc:116

  int32_t numerator, denominator;
  if (GetMscRate(&numerator, &denominator) && numerator) {
    last_computed_intervals_.push(base::TimeDelta::FromSeconds(denominator) /
                                  numerator);
  } else if (!last_timebase_.is_null()) {
    base::TimeDelta timebase_diff = timebase - last_timebase_;
    int64_t counter_diff = media_stream_counter - last_media_stream_counter_;
    if (counter_diff > 0 && timebase > last_timebase_)
      last_computed_intervals_.push(timebase_diff / counter_diff);
  }

  if (last_computed_intervals_.size() == 2) {
    const base::TimeDelta& old_interval = last_computed_intervals_.front();
    const base::TimeDelta& new_interval = last_computed_intervals_.back();

    double relative_change =
        fabs(old_interval.InMillisecondsF() - new_interval.InMillisecondsF()) /
        new_interval.InMillisecondsF();
    if (relative_change < kRelativeIntervalDifferenceThreshold) {
      if (new_interval.InMicroseconds() < kMinVsyncIntervalUs ||
          new_interval.InMicroseconds() > kMaxVsyncIntervalUs) {
        // For ChromeOS, we get the refresh interval from DRM through Ozone.
        // For Linux, we could use XRandR.
        // http://crbug.com/340851
        LOG(ERROR)
            << "Calculated bogus refresh interval=" << new_interval
            << ", last_timebase_=" << last_timebase_
            << ", timebase=" << timebase
            << ", last_media_stream_counter_=" << last_media_stream_counter_
            << ", media_stream_counter=" << media_stream_counter;
      } else {
        last_good_interval_ = new_interval;
      }
    }
  }

Perhaps the approximation was tuned based on xwayland-1.19 branch and I guess it broke when xwayland-1.20 branch added multi-buffering support that changed how drawable surfaces were flipped. Hence, we got logs storm of "Calculated bogus refresh interval" errors.

When playing a video I get a bunch of these in the terminal output:

[83611:83611:1016/001304.080118:ERROR:sync_control_vsync_provider.cc(140)] Calculated bogus refresh interval=1.00016 s, last_timebase_=93179083446 bogo-microseconds, timebase=93180083604 bogo-microseconds, last_media_stream_counter_=504, media_stream_counter=505

So a workaround is to use XRandR APIs to obtain current refresh rate in place of the ANGLE-specific EGL extensions on the EGL code path.

-- ../../orig/chromium-81.0.4044.138/ui/gl/gl_surface_egl.cc   2020-05-07 19:20:59.374363241 -0700
+++ ./ui/gl/gl_surface_egl.cc   2020-05-07 17:48:42.745076487 -0700
@@ -268,7 +268,12 @@

   bool GetMscRate(int32_t* numerator, int32_t* denominator) override {
     if (!g_egl_sync_control_rate_supported) {
-      return false;
+      Window root = DefaultRootWindow(gfx::GetXDisplay());
+      XRRScreenConfiguration *conf = XRRGetScreenInfo(gfx::GetXDisplay(), root);
+      short curr_rate = XRRConfigCurrentRate(conf);
+      *numerator = static_cast<int32_t>(curr_rate);
+      *denominator = 1;
+      return true;
     }

     bool result = eglGetMscRateANGLE(g_egl_display, surface_, numerator,

This is not an ideal fix though as EGL code path should be free of any X11 binding APIs. We have no choice because there isn't any alternative methods available from MESA OpenGL ES implementation to do the same. I wish to be corrected if anyone more experienced with OpenGL ES can shed some lights on it.

liewkj

Member

Registered: 2019-07-08

Posts: 210

Re: chromium: hardware video acceleration with VA-API

The clean solution is for MESA EGL to implement EGL_ANGLE_sync_control_rate.
Bug filed https://gitlab.freedesktop.org/mesa/mesa/-/issues/2930

Once MESA EGL added the implementation, the following Chromium issue is resolved, too. Both Intel (i965, iHD) and MESA VA-API drivers (r600, radeonsi) work equally great on both X11 and Wayland session regardless of GL backends.

Issue 1041228: Poor performance with --use-gl=egl on XWayland (GNOME/Wayland)

Martine

Member

Registered: 2019-11-07

Posts: 5

Re: chromium: hardware video acceleration with VA-API

Edit: solved the InitializeSandbox error with MESA_GLSL_CACHE_DISABLE=true, but the hardware decoding problem persists.

I can't get hardware video decoding working on my ancient Intel G45 (using libva-intel-driver-g45-h264) with chromium 81.0.4044.138. Using X. Everything checks out until I play a YouTube Video. Chrome says

[18154:18154:0513/145232.499472:ERROR:sandbox_linux.cc(374)] InitializeSandbox() called with multiple threads in process gpu-process.
[18154:18154:0513/145307.065220:ERROR:vaapi_video_decode_accelerator.cc(689)] Failed to initialize VppVaapiWrapper
[18327:13:0513/145307.065785:ERROR:batching_media_log.cc(38)] MediaEvent: {"error":"VDA Error 4"}

And media-internals log:

00:00:00.333	info	"Effective playback rate changed from 0 to 1"
00:00:00.334	event	"kPlay"
00:00:00.862	debug	"ISO-BMFF container metadata for video frame indicates that the frame is a keyframe, but the video frame contents indicate the opposite."
00:00:00.585	duration	216.270657
00:00:02.285	kIsAudioDecryptingDemuxerStream	false
00:00:02.285	kAudioDecoderName	"FFmpegAudioDecoder"
00:00:02.285	kIsPlatformAudioDecoder	false
00:00:02.285	info	"Selected FFmpegAudioDecoder for audio decoding, config: codec: aac, profile: unknown, bytes_per_channel: 2, channel_layout: STEREO, channels: 2, samples_per_second: 44100, sample_format: Signed 16-bit, bytes_per_frame: 4, seek_preroll: 0us, codec_delay: 0, has extra data: false, encryption scheme: Unencrypted, discard decoder delay: false"
00:00:02.368	kIsVideoDecryptingDemuxerStream	false
00:00:02.368	kVideoDecoderName	"MojoVideoDecoder"
00:00:02.368	kIsPlatformVideoDecoder	true
00:00:02.368	info	"Selected MojoVideoDecoder for video decoding, config: codec: h264, profile: h264 main, level: not available, alpha_mode: is_opaque, coded size: [854,480], visible rect: [0,0,854,480], natural size: [854,480], has extra data: false, encryption scheme: Unencrypted, rotation: 0°, flipped: 0, color space: {primaries:BT709, transfer:BT709, matrix:BT709, range:LIMITED}"
00:00:02.368	pipeline_state	"kPlaying"
00:00:02.370	audio_buffering_state	{"state":"BUFFERING_HAVE_ENOUGH"}
00:00:02.385	error	"VDA Error 4"
00:00:02.386	warning	"video fallback to new decoder after initial decode error."
00:00:02.388	kIsVideoDecryptingDemuxerStream	false
00:00:02.388	kVideoDecoderName	"FFmpegVideoDecoder"
00:00:02.388	kIsPlatformVideoDecoder	false

Thanks for looking into it!

Last edited by Martine (2020-05-13 13:29:54)

liewkj

Member

Registered: 2019-07-08

Posts: 210

Re: chromium: hardware video acceleration with VA-API

I can't get hardware video decoding working on my ancient Intel G45 (using libva-intel-driver-g45-h264) with chromium 81.0.4044.138. Using X. Everything checks out until I play a YouTube Video. Chrome says

[18154:18154:0513/145232.499472:ERROR:sandbox_linux.cc(374)] InitializeSandbox() called with multiple threads in process gpu-process.
[18154:18154:0513/145307.065220:ERROR:vaapi_video_decode_accelerator.cc(689)] Failed to initialize VppVaapiWrapper
[18327:13:0513/145307.065785:ERROR:batching_media_log.cc(38)] MediaEvent: {"error":"VDA Error 4"}

The error sounds like you would also have issue with vainfo. Please check if vainfo is also reporting initialization error.
Did you compile your own chromium to enable vaapi?
It will also be helpful if you can show the command line of how chromium was started. You can get the information from chrome://gpu in the row of "Command Line".

Martine

Member

Registered: 2019-11-07

Posts: 5

Re: chromium: hardware video acceleration with VA-API

Edit: somehow I missed the start of the error when starting chromium from console. The complete output until I start a video is this:

[77142:77142:0515/140242.022118:ERROR:vaapi_wrapper.cc(586)] GetConfigAttributes failed for va_profile VAProfileH264ConstrainedBaseline
[77142:77142:0515/140242.022278:ERROR:vaapi_wrapper.cc(586)] GetConfigAttributes failed for va_profile VAProfileH264Main
[77142:77142:0515/140242.022502:ERROR:vaapi_wrapper.cc(586)] GetConfigAttributes failed for va_profile VAProfileH264High
[77142:77142:0515/140242.166492:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[77142:77142:0515/140242.166587:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[77142:77142:0515/140242.166631:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[77142:77142:0515/140242.166671:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[77142:77142:0515/140242.166707:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[77142:77142:0515/140242.166743:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[77142:77142:0515/140242.166788:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[77142:77142:0515/140242.166829:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[77142:77142:0515/140242.166867:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[77142:77142:0515/140242.166900:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[77142:77142:0515/140242.166935:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[77142:77142:0515/140242.166976:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[77142:77142:0515/140242.167013:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[77142:77142:0515/140242.167045:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[77142:77142:0515/140242.167090:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[77142:77142:0515/140242.167134:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[77142:77142:0515/140242.167174:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[77142:77142:0515/140242.167211:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[77142:77142:0515/140242.167256:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[77142:77142:0515/140242.167292:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[77142:77142:0515/140242.167334:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[77142:77142:0515/140242.167379:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[77142:77142:0515/140242.167416:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[77142:77142:0515/140242.167460:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[77142:77142:0515/140242.167498:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[77142:77142:0515/140242.167539:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[77142:77142:0515/140242.167578:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[77142:77142:0515/140242.167619:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[77142:77142:0515/140242.167658:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[77142:77142:0515/140242.167696:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[77142:77142:0515/140242.167747:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[77142:77142:0515/140242.167785:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[77142:77142:0515/140242.188315:ERROR:sandbox_linux.cc(374)] InitializeSandbox() called with multiple threads in process gpu-process.
[77120:77120:0515/140242.747556:ERROR:browser_switcher_service.cc(238)] XXX Init()
[77142:77142:0515/140303.819249:ERROR:vaapi_video_decode_accelerator.cc(689)] Failed to initialize VppVaapiWrapper
[77272:15:0515/140303.820017:ERROR:batching_media_log.cc(38)] MediaEvent: {"error":"VDA Error 4"}

The error sounds like you would also have issue with vainfo. Please check if vainfo is also reporting initialization error.

My vainfo reports this.

vainfo: VA-API version: 1.7 (libva 2.7.1)
vainfo: Driver version: Intel i965 driver for Intel(R) GM45 Express Chipset - 2.4.0
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointVLD

Hardware acceleration is working when using mpv for playing H.264 videos

Did you compile your own chromium to enable vaapi?

No,I will try to do it.

It will also be helpful if you can show the command line of how chromium was started. You can get the information from chrome://gpu in the row of "Command Line".

/usr/lib/chromium/chromium --ignore-gpu-blacklist --enable-gpu-rasterization --enable-native-gpu-memory-buffers --enable-zero-copy --disable-gpu-driver-bug-workarounds --num-raster-threads=4 --flag-switches-begin --enable-gpu-rasterization --enable-zero-copy --flag-switches-end --disable-webrtc-apm-in-audio-service

Last edited by Martine (2020-05-15 12:13:15)

liewkj

Member

Registered: 2019-07-08

Posts: 210

Re: chromium: hardware video acceleration with VA-API

Did you compile your own chromium to enable vaapi?

No,I will try to do it.

No, you don't have to unless you have access to powerful multi-core build machine. Otherwise it may take days for anything less than a quad-core and 8GB RAM.
However, it would be nice that you also show me the build you sourced from so that I can try it out, too. I have proposed 2 fixes to AUR chromium-vaapi, but they are meant for Wayland. I don't expect those issues to apply if you use X. You can find them in the message area of the AUR package.

In the meantime, I can only recommend that you remove the `--enable-native-gpu-memory-buffers` flag or just keep the `--ignore-gpu-blacklist` and remove everything else for debugging.

The oldest Intel GPU I can check is a Sandybridge Celeron 847 laptop. The GM45 is obviously a very old platform, but as long as vainfo looks fine it should work, especially for H.264.

Martine

Member

Registered: 2019-11-07

Posts: 5

Re: chromium: hardware video acceleration with VA-API

No, you don't have to unless you have access to powerful multi-core build machine. Otherwise it may take days for anything less than a quad-core and 8GB RAM.

Already running for 24hrs. :-) Let's see if it will finish (2/3rd from build)

However, it would be nice that you also show me the build you sourced from so that I can try it out, too. I have proposed 2 fixes to AUR chromium-vaapi, but they are meant for Wayland. I don't expect those issues to apply if you use X. You can find them in the message area of the AUR package.

Yes, I see it. I use the chromium package from the archlinuxcn repository: https://github.com/archlinuxcn/repo

In the meantime, I can only recommend that you remove the `--enable-native-gpu-memory-buffers` flag or just keep the `--ignore-gpu-blacklist` and remove everything else for debugging.

The oldest Intel GPU I can check is a Sandybridge Celeron 847 laptop. The GM45 is obviously a very old platform, but as long as vainfo looks fine it should work, especially for H.264.

Thanks, I will play with the settings. Will report back.

Martine

Member

Registered: 2019-11-07

Posts: 5

Re: chromium: hardware video acceleration with VA-API

I tried running chromium with only the --ignore-gpu-blacklist and this is the output:

[39747:39747:0516/155738.204032:ERROR:browser_switcher_service.cc(238)] XXX Init()
[39774:39774:0516/155738.375799:ERROR:vaapi_wrapper.cc(586)] GetConfigAttributes failed for va_profile VAProfileH264ConstrainedBaseline
[39774:39774:0516/155738.382760:ERROR:vaapi_wrapper.cc(586)] GetConfigAttributes failed for va_profile VAProfileH264Main
[39774:39774:0516/155738.385896:ERROR:vaapi_wrapper.cc(586)] GetConfigAttributes failed for va_profile VAProfileH264High
[39774:39774:0516/155738.583836:ERROR:sandbox_linux.cc(374)] InitializeSandbox() called with multiple threads in process gpu-process.
[39774:39839:0516/155738.677137:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[39774:39839:0516/155738.706791:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[39774:39839:0516/155738.719313:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[39774:39839:0516/155738.719610:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[39774:39839:0516/155738.722816:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[39774:39839:0516/155738.723102:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[39774:39839:0516/155738.723299:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[39774:39839:0516/155738.723476:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[39774:39839:0516/155738.723728:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[39774:39839:0516/155738.723990:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[39774:39839:0516/155738.724295:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[39774:39839:0516/155738.724492:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[39774:39839:0516/155738.724661:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[39774:39839:0516/155738.724862:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[39774:39839:0516/155738.725045:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[39774:39839:0516/155738.725234:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[39774:39839:0516/155738.725419:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[39774:39839:0516/155738.725608:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[39774:39839:0516/155738.726968:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[39774:39839:0516/155738.727198:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[39774:39839:0516/155738.727375:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[39774:39839:0516/155738.727533:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[39774:39839:0516/155738.727718:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[39774:39839:0516/155738.727910:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[39774:39839:0516/155738.728082:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[39774:39839:0516/155738.729303:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[39774:39839:0516/155738.740021:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[39774:39839:0516/155738.740231:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[39774:39839:0516/155738.740450:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[39774:39839:0516/155738.740652:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[39774:39839:0516/155738.741288:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[39774:39839:0516/155738.741531:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: No such file or directory (2)
[39774:39774:0516/155800.695754:ERROR:vaapi_video_decode_accelerator.cc(689)] Failed to initialize VppVaapiWrapper
[39936:13:0516/155800.696695:ERROR:batching_media_log.cc(38)] MediaEvent: {"error":"VDA Error 4"}

liewkj

Member

Registered: 2019-07-08

Posts: 210

Re: chromium: hardware video acceleration with VA-API

My vainfo reports this.

vainfo: VA-API version: 1.7 (libva 2.7.1)
vainfo: Driver version: Intel i965 driver for Intel(R) GM45 Express Chipset - 2.4.0
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointVLD

Hardware acceleration is working when using mpv for playing H.264 videos

I am sorry I overlooked your vainfo details. Your VA driver is missing `VAProfileNone` which is required by chromium-vaapi. Outside of chromium, mpv and gstreamer-vaapi may not require it if their VA-API support was designed around libva <=2.0.0.

xuanrui

Member

Registered: 2018-09-27

Posts: 52

Re: chromium: hardware video acceleration with VA-API

Hi all, not sure if this is a VA-API related issue but I strongly suspect so; with the NVIDIA proprietary driver installed and KMS enabled, I encounter occasional display problems (familiar blurred window) and very occasional spontaneous exits. There are no errors printed if I start Chromium from a terminal. I tried disabling KMS and the problem seems to have gone away.

Anyone experiencing the same issues with KMS-enabled NVIDIA driver?