You are not logged in.

#226 2019-10-24 13:17:45

akarshanbiswas
Member
Registered: 2019-06-22
Posts: 33

Re: chromium: hardware video acceleration with VA-API

maximbaz wrote:

Seems like there's a new decoder in Chromium 78, I see Dav1dVideoDecoder instead of MojoVideoDecoder when playing a youtube video, please post here if you experience any issues.

That's VLC's av1 decoder! Wait, So, youtube now defaults to dav1d instead of libvpx huh?

Offline

#227 2019-10-24 15:41:47

maximbaz
Package Maintainer (PM)
Registered: 2017-12-28
Posts: 54

Re: chromium: hardware video acceleration with VA-API

I've just checked again on a few videos using both vp9 and h264 and I can only get Mojo to appear, I don't know how I managed to get dav1d before, and I don't remember on what video I tried smile

Offline

#228 2019-10-24 15:57:48

akarshanbiswas
Member
Registered: 2019-06-22
Posts: 33

Re: chromium: hardware video acceleration with VA-API

maximbaz wrote:

I've just checked again on a few videos using both vp9 and h264 and I can only get Mojo to appear, I don't know how I managed to get dav1d before, and I don't remember on what video I tried smile

You can test this youtube video: https://www.youtube.com/watch?v=w4LkSRXrK34

Offline

#229 2019-10-24 16:30:59

maximbaz
Package Maintainer (PM)
Registered: 2017-12-28
Posts: 54

Re: chromium: hardware video acceleration with VA-API

Yes, I see dav1d on this video!

Offline

#230 2019-10-24 19:24:58

liewkj
Member
Registered: 2019-07-08
Posts: 210

Re: chromium: hardware video acceleration with VA-API

The new AV1 video format has no hardware accelerated video decoder yet. It's the same league as the rest of software decoders such as FFmepgVideoDecoder and VpxVideoDecoder. IIRC, Google scrapped the plan for VP10 and moved on with AV1 as the next royalty-free video standard for the Internet. MojoVideoDecoder remains the factory for hardware accelerated supported video formats such as H.264 and VP9. The enhanced-h264ify extension can block AV1 format from Youtube to get hardware acceleration into action.

Last edited by liewkj (2019-10-24 19:27:33)

Offline

#231 2019-10-24 23:24:17

liewkj
Member
Registered: 2019-07-08
Posts: 210

Re: chromium: hardware video acceleration with VA-API

yabk wrote:

It is using MojoVideoDecoder and it's still laggy.

If you have the capacity to recompile Chromium from source, then you may want to try the pristine upstream with "use=vaapi" build flag. This let you experiment if the VPP skipping conditional code block is doing any better for your situation. If this is not making any difference, then there is no other way other than complaining/filing bugs to Intel on your situation, if you don't want to give up Wayland for hardware accelerated video decode. Or, just patiently wait for Intel to improve the drivers, or get an AMD Ryzen APU tongue

Offline

#232 2019-10-25 03:38:11

liewkj
Member
Registered: 2019-07-08
Posts: 210

Re: chromium: hardware video acceleration with VA-API

yabk wrote:

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

I got the same terminal output when running Chromium with "--use-gl=egl" on Ryzen APU w/ Vega graphics, so I guess Wayland is still troublesome for Chromium VA-API support. And, yes, while MojoVideoDecoder was in used, YouTube videos was choppy and kept dropping frames even at 720p. This was similar observation from Maximbaz on his Kabylake generation of Intel graphics.

Fortunately, I don't have to use it, the default "--use-gl=desktop" works fine on Wayland.

I don't know how others could have reported success stories of using "--use-gl=egl" on Wayland session, but good for them anyway if it really did.

Last edited by liewkj (2019-10-25 03:39:03)

Offline

#233 2019-10-25 17:48:13

justkdng
Member
From: 日本
Registered: 2019-10-08
Posts: 46

Re: chromium: hardware video acceleration with VA-API

V1del wrote:

chromium actively filters the environment for a very select few variables it considers "safe" so this isn't really surprising

Figures, I'll just use my integrated GPU for now, unless I can get chromium to run with vulkan.

maximbaz wrote:

Seems like there's a new decoder in Chromium 78, I see Dav1dVideoDecoder instead of MojoVideoDecoder when playing a youtube video, please post here if you experience any issues.

Actually, that decoder has been up since 77.x


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

Offline

#234 2019-10-26 00:51:19

CarbonChauvinist
Member
Registered: 2012-06-16
Posts: 412
Website

Re: chromium: hardware video acceleration with VA-API

Wait, am I some kind of unicorn? Now I'm by no means a videophile, but the videos are not lagging or excessively choppy in any way when using the egl flag in Wayland. In fact, just to make sure I tested the same video using the latest chromium-vaapi-bin (78.0.3904.70-1) and the vanilla extra/chromium (78.0.3904.70-1) and both played the same -- to my eyes at least.

Here's the log from media internals from watching this video. Is there anything else that might be helpful from my setup?

Last edited by CarbonChauvinist (2019-10-26 00:54:07)


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

Offline

#235 2019-10-26 05:40:48

liewkj
Member
Registered: 2019-07-08
Posts: 210

Re: chromium: hardware video acceleration with VA-API

There is one major difference, KabyLake+ and Ryzen APU support VP9, and we were checking out VP9.

Offline

#236 2019-10-26 18:32:46

justkdng
Member
From: 日本
Registered: 2019-10-08
Posts: 46

Re: chromium: hardware video acceleration with VA-API

CarbonChauvinist wrote:

Is there anything else that might be helpful from my setup?

It depends tbh. Hardware acceleration, for regular video streaming, is used to reduce the power usage of the cpu and/or help the cpu with high quality streams (1080 w/ 60fps) if the cpu is not powerful enough. If you have a strong CPU it will play the streams smothly with just it but the power usage will be more than if you used your GPU.
Hardware Acceleration won't magically make the video look better since there is no way to configure scaling, interpolation, etc. For that there is stuff like MPV, in those cases hardware acceleration is used to aid the CPU and not to reduce power usage. That is how I view it.
Also, its nice to be able to do other stuff while compiling.


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

Offline

#237 2019-10-27 08:21:35

sapjunior
Member
Registered: 2019-10-27
Posts: 3

Re: chromium: hardware video acceleration with VA-API

Is there any hope for chromium-vaapi on Xwayland (intel uhd620)?

Offline

#238 2019-10-29 03:59:26

justkdng
Member
From: 日本
Registered: 2019-10-08
Posts: 46

Re: chromium: hardware video acceleration with VA-API

sapjunior wrote:

Is there any hope for chromium-vaapi on Xwayland (intel uhd620)?

See

liewkj wrote:

Intel's priority and focus have since moved on to iHD driver. The old i965 VA drivers was left as the open source playing ground, and up to the community for making miracles.


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

Offline

#239 2019-11-16 18:58:46

Master One
Member
From: Europe
Registered: 2007-01-21
Posts: 249

Re: chromium: hardware video acceleration with VA-API

I have played around with this today as well and sadly it just doesn't work. The environment is an up-to-date Arch Linux with GNOME on Wayland with Intel UHD620, all steps for HW acceleration from the Wiki for Chromium and gstreamer are checked, tests were performed with VA-API enabled ungoogled-chromium and Totem checked by running intel_gpu_top.

$ chromium
[9718:9718:1116/192905.424491:ERROR:child_process_security_policy_impl.cc(1477)] Invalid isolated origin: 
libva error: va_getDriverName() failed with unknown libva error,driver_name=(null)
[9746:9746:1116/192905.512648:ERROR:vaapi_wrapper.cc(399)] vaInitialize failed: unknown libva error
[9746:9746:1116/192905.551787:ERROR:sandbox_linux.cc(369)] InitializeSandbox() called with multiple threads in process gpu-process.
[9746:9746:1116/192905.757482:ERROR:buffer_manager.cc(488)] [.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error from previous GL command
Fontconfig error: Cannot load default config file
[9746:9746:1116/192906.766055:ERROR:gl_surface_presentation_helper.cc(259)] GetVSyncParametersIfAvailable() failed for 1 times!
[9746:9746:1116/192906.782684:ERROR:gl_surface_presentation_helper.cc(259)] GetVSyncParametersIfAvailable() failed for 2 times!
.
.
[9746:9746:1116/192906.975705:ERROR:gl_surface_presentation_helper.cc(259)] GetVSyncParametersIfAvailable() failed for 18 times!
[9746:9746:1116/192906.981498:ERROR:gl_surface_presentation_helper.cc(259)] GetVSyncParametersIfAvailable() failed for 19 times!
$ LIBVA_DRIVER_NAME=i965 chromium
[10268:10268:1116/192959.050159:ERROR:child_process_security_policy_impl.cc(1477)] Invalid isolated origin: 
libva error: /usr/lib/dri/i965_drv_video.so init failed
[10295:10295:1116/192959.141055:ERROR:vaapi_wrapper.cc(399)] vaInitialize failed: unknown libva error
[10295:10295:1116/192959.186398:ERROR:sandbox_linux.cc(369)] InitializeSandbox() called with multiple threads in process gpu-process.
[10295:10295:1116/192959.375315:ERROR:buffer_manager.cc(488)] [.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error from previous GL command
[10295:10295:1116/193000.403832:ERROR:gl_surface_presentation_helper.cc(259)] GetVSyncParametersIfAvailable() failed for 1 times!
[10295:10295:1116/193000.421222:ERROR:gl_surface_presentation_helper.cc(259)] GetVSyncParametersIfAvailable() failed for 2 times!
.
.
[10295:10295:1116/193000.821057:ERROR:gl_surface_presentation_helper.cc(259)] GetVSyncParametersIfAvailable() failed for 18 times!
[10295:10295:1116/193000.823546:ERROR:gl_surface_presentation_helper.cc(259)] GetVSyncParametersIfAvailable() failed for 19 times!
$ LIBVA_DRIVER_NAME=iHD chromium
[10531:10531:1116/193026.614224:ERROR:child_process_security_policy_impl.cc(1477)] Invalid isolated origin: 
[10558:10558:1116/193026.768618:ERROR:sandbox_linux.cc(369)] InitializeSandbox() called with multiple threads in process gpu-process.
[10558:10558:1116/193026.926449:ERROR:buffer_manager.cc(488)] [.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error from previous GL command
[10558:10558:1116/193027.912381:ERROR:gl_surface_presentation_helper.cc(259)] GetVSyncParametersIfAvailable() failed for 1 times!
[10558:10558:1116/193027.929038:ERROR:gl_surface_presentation_helper.cc(259)] GetVSyncParametersIfAvailable() failed for 2 times!
.
.
[10558:10558:1116/193028.231432:ERROR:gl_surface_presentation_helper.cc(259)] GetVSyncParametersIfAvailable() failed for 18 times!
[10558:10558:1116/193028.277315:ERROR:gl_surface_presentation_helper.cc(259)] GetVSyncParametersIfAvailable() failed for 19 times!

So on Wayland LIBVA_DRIVER_NAME has to be set, otherwise libva can's be initialized.

Wayland support is not enabled in any Chromium build yet (except chromium-ozone) and XWayland is broken on libva-intel-driver , so the only chance would have been using intel-media-driver (= LIBVA_DRIVER_NAME=iHD) which does not cause that libva init error but doesn't work either.

The same goes for Totem, so there obviously must be a connection to that problem as well.

Interestingly the following seems to kind of work:

$ LIBVA_DRIVER_NAME=iHD chromium --use-gl=egl
[11070:11070:1116/194656.245806:ERROR:child_process_security_policy_impl.cc(1477)] Invalid isolated origin: 
[11098:11098:1116/194656.357195:ERROR:sandbox_linux.cc(369)] InitializeSandbox() called with multiple threads in process gpu-process.
[11098:11098:1116/194701.439473:ERROR:sync_control_vsync_provider.cc(140)] Calculated bogus refresh interval=0.283083 s, last_timebase_=9924528390 bogo-microseconds, timebase=9924811473 bogo-microseconds, last_media_stream_counter_=92, media_stream_counter=93
[11098:11098:1116/194702.820854:ERROR:gl_surface_presentation_helper.cc(259)] GetVSyncParametersIfAvailable() failed for 1 times!
[11098:11098:1116/194704.653664:ERROR:sync_control_vsync_provider.cc(140)] Calculated bogus refresh interval=0.599319 s, last_timebase_=9927412348 bogo-microseconds, timebase=9928011667 bogo-microseconds, last_media_stream_counter_=99, media_stream_counter=100
[11098:11098:1116/194705.252559:ERROR:sync_control_vsync_provider.cc(140)] Calculated bogus refresh interval=0.599884 s, last_timebase_=9928011667 bogo-microseconds, timebase=9928611551 bogo-microseconds, last_media_stream_counter_=100, media_stream_counter=101
[11098:11098:1116/194705.852448:ERROR:sync_control_vsync_provider.cc(140)] Calculated bogus refresh interval=0.600821 s, last_timebase_=9928611551 bogo-microseconds, timebase=9929212372 bogo-microseconds, last_media_stream_counter_=101, media_stream_counter=102
[11098:11098:1116/194706.453162:ERROR:sync_control_vsync_provider.cc(140)] Calculated bogus refresh interval=0.599804 s, last_timebase_=9929212372 bogo-microseconds, timebase=9929812176 bogo-microseconds, last_media_stream_counter_=102, media_stream_counter=103
[11098:11098:1116/194707.053328:ERROR:sync_control_vsync_provider.cc(140)] Calculated bogus refresh interval=0.600112 s, last_timebase_=9929812176 bogo-microseconds, timebase=9930412288 bogo-microseconds, last_media_stream_counter_=103, media_stream_counter=104
[11098:11098:1116/194707.653273:ERROR:sync_control_vsync_provider.cc(140)] Calculated bogus refresh interval=0.599993 s, last_timebase_=9930412288 bogo-microseconds, timebase=9931012281 bogo-microseconds, last_media_stream_counter_=104, media_stream_counter=105
[11098:11098:1116/194708.818191:ERROR:sync_control_vsync_provider.cc(140)] Calculated bogus refresh interval=0.598961 s, last_timebase_=9931012281 bogo-microseconds, timebase=9931611242 bogo-microseconds, last_media_stream_counter_=105, media_stream_counter=106
[11098:11098:1116/194708.851691:ERROR:sync_control_vsync_provider.cc(140)] Calculated bogus refresh interval=0.599617 s, last_timebase_=9931611242 bogo-microseconds, timebase=9932210859 bogo-microseconds, last_media_stream_counter_=106, media_stream_counter=107
[11098:11098:1116/194709.452190:ERROR:sync_control_vsync_provider.cc(140)] Calculated bogus refresh interval=0.601268 s, last_timebase_=9932210859 bogo-microseconds, timebase=9932812127 bogo-microseconds, last_media_stream_counter_=107, media_stream_counter=108
[11098:11098:1116/194710.053346:ERROR:sync_control_vsync_provider.cc(140)] Calculated bogus refresh interval=0.600092 s, last_timebase_=9932812127 bogo-microseconds, timebase=9933412219 bogo-microseconds, last_media_stream_counter_=108, media_stream_counter=109
[11098:11098:1116/194710.653138:ERROR:sync_control_vsync_provider.cc(140)] Calculated bogus refresh interval=0.599928 s, last_timebase_=9933412219 bogo-microseconds, timebase=9934012147 bogo-microseconds, last_media_stream_counter_=109, media_stream_counter=110
[11098:11098:1116/194711.253262:ERROR:sync_control_vsync_provider.cc(140)] Calculated bogus refresh interval=0.617123 s, last_timebase_=9934012147 bogo-microseconds, timebase=9934629270 bogo-microseconds, last_media_stream_counter_=110, media_stream_counter=111
[11098:11098:1116/194713.627737:ERROR:sync_control_vsync_provider.cc(140)] Calculated bogus refresh interval=0.600056 s, last_timebase_=9935812342 bogo-microseconds, timebase=9936412398 bogo-microseconds, last_media_stream_counter_=119, media_stream_counter=120
[11098:11098:1116/194713.673926:ERROR:sync_control_vsync_provider.cc(140)] Calculated bogus refresh interval=0.617617 s, last_timebase_=9936412398 bogo-microseconds, timebase=9937030015 bogo-microseconds, last_media_stream_counter_=120, media_stream_counter=121
[11098:11098:1116/194719.069781:ERROR:texture_manager.cc(3652)] [.DisplayCompositor]GL ERROR :GL_INVALID_ENUM : glTexImage2D: <- error from previous GL command
Fontconfig error: Cannot load default config file
[11098:11098:1116/194724.611430:ERROR:gl_surface_presentation_helper.cc(259)] GetVSyncParametersIfAvailable() failed for 2 times!
[11098:11098:1116/194728.059715:ERROR:gl_surface_presentation_helper.cc(259)] GetVSyncParametersIfAvailable() failed for 3 times!
[11098:11098:1116/194728.065334:ERROR:gl_surface_presentation_helper.cc(259)] GetVSyncParametersIfAvailable() failed for 4 times!
[11098:11098:1116/194731.165807:ERROR:gl_surface_presentation_helper.cc(259)] GetVSyncParametersIfAvailable() failed for 5 times!
[11098:11098:1116/194751.567848:ERROR:gl_surface_presentation_helper.cc(259)] GetVSyncParametersIfAvailable() failed for 6 times!
[11098:11098:1116/194754.947312:ERROR:gl_surface_presentation_helper.cc(259)] GetVSyncParametersIfAvailable() failed for 7 times!
[11098:11098:1116/194804.042333:ERROR:gl_surface_presentation_helper.cc(259)] GetVSyncParametersIfAvailable() failed for 8 times!
[11098:11098:1116/194805.321450:ERROR:gl_surface_presentation_helper.cc(259)] GetVSyncParametersIfAvailable() failed for 9 times!
[11098:11098:1116/194808.748382:ERROR:sync_control_vsync_provider.cc(140)] Calculated bogus refresh interval=0.28347 s, last_timebase_=9991563532 bogo-microseconds, timebase=9991847002 bogo-microseconds, last_media_stream_counter_=801, media_stream_counter=802
[11098:11098:1116/194813.389387:ERROR:gl_surface_presentation_helper.cc(259)] GetVSyncParametersIfAvailable() failed for 10 times!
[11098:11098:1116/194816.124018:ERROR:gl_surface_presentation_helper.cc(259)] GetVSyncParametersIfAvailable() failed for 11 times!
[11098:11098:1116/194827.338286:ERROR:gl_surface_presentation_helper.cc(259)] GetVSyncParametersIfAvailable() failed for 12 times!
[11098:11098:1116/194834.059088:ERROR:gl_surface_presentation_helper.cc(259)] GetVSyncParametersIfAvailable() failed for 13 times!
[11098:11098:1116/194834.062715:ERROR:gl_surface_presentation_helper.cc(259)] GetVSyncParametersIfAvailable() failed for 14 times!
^T[11098:11098:1116/194854.641096:ERROR:gl_surface_presentation_helper.cc(259)] GetVSyncParametersIfAvailable() failed for 15 times!
[11098:11098:1116/194854.645574:ERROR:gl_surface_presentation_helper.cc(259)] GetVSyncParametersIfAvailable() failed for 16 times!
[11098:11098:1116/194916.967280:ERROR:gles2_cmd_decoder.cc(18470)] [.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glCreateAndConsumeTextureCHROMIUM: invalid mailbox name
[11098:11098:1116/194916.967341:ERROR:gles2_cmd_decoder.cc(10752)] [.DisplayCompositor]RENDER WARNING: texture bound to texture unit 0 is not renderable. It might be non-power-of-2 or have incompatible texture filtering (maybe)?
[11098:11098:1116/194948.763537:ERROR:sync_control_vsync_provider.cc(140)] Calculated bogus refresh interval=0.116652 s, last_timebase_=10092017926 bogo-microseconds, timebase=10092134578 bogo-microseconds, last_media_stream_counter_=2204, media_stream_counter=2205
[11098:11098:1116/195023.665888:ERROR:sync_control_vsync_provider.cc(140)] Calculated bogus refresh interval=0.100647 s, last_timebase_=10126885859 bogo-microseconds, timebase=10126986506 bogo-microseconds, last_media_stream_counter_=2674, media_stream_counter=2675
[11098:11098:1116/195023.932647:ERROR:sync_control_vsync_provider.cc(140)] Calculated bogus refresh interval=0.100314 s, last_timebase_=10127152339 bogo-microseconds, timebase=10127252653 bogo-microseconds, last_media_stream_counter_=2677, media_stream_counter=2678
[11098:11098:1116/195030.117949:ERROR:sync_control_vsync_provider.cc(140)] Calculated bogus refresh interval=0.117157 s, last_timebase_=10133369745 bogo-microseconds, timebase=10133486902 bogo-microseconds, last_media_stream_counter_=2748, media_stream_counter=2749
[11098:11098:1116/195036.449656:ERROR:gl_surface_presentation_helper.cc(259)] GetVSyncParametersIfAvailable() failed for 17 times!
[11098:11098:1116/195044.424586:ERROR:gl_surface_presentation_helper.cc(259)] GetVSyncParametersIfAvailable() failed for 18 times!
[11098:11098:1116/195051.517145:ERROR:gl_surface_presentation_helper.cc(259)] GetVSyncParametersIfAvailable() failed for 19 times!

Resulting in intel_gpu_top finally showing some action:

egl.png

But the video does not seem to run smooth.

Running GNOME in an X11 session and the problems are gone, but obviously that's not the point in using a recent GNOME.

I don't have enough insight to analyze this any further, maybe someone else can provide more up-to-date information about that matter?

Offline

#240 2019-11-20 13:26:06

mirh
Member
Registered: 2016-04-09
Posts: 32

Re: chromium: hardware video acceleration with VA-API

maximbaz wrote:

GeForce GTX 750 SE and after support HEVC and VP9 video decoding but VDPAU,the only VAAPI backend available for Nvidia users with libva-vdpau-driver, doesn't support VP8/9.

4 ways to solve this:

- Add VP9 support to VDPAU but it hasn't been actively maintained since at least 3 years

Well, this happened this summer.

liewkj wrote:

I seriously doubt if this actually works for ChromeOS, unless they have a specially crafted, locked-down kernel, Intel VA drivers and libva for meeting a strict power numbers for their OEM customers. Yes, I am convinced that skipping VPP is indeed a power optimization after scanning through upstream Chromium commit history. It sounds more like a test hole from code refactoring or back integration from Chromium/master into release branches. After all, none of the ChromeOS device was shipping with GeminiLake/KabyLake+ until recently. Most of them were ApolloLake on the values and SkyLake on the high-ends.

They were pretty much in touch with the intel engineers actually, and they really had measured something counterproductive indeed.
So they may have had all the information required to take this decision.

If any though, it doesn't make sense that APL is out. Even assuming there were issues with the hybrid codec (because of the usual bugs, or even due to a design shortcoming), that supposedly had the first completely fixed function VP9 block.

Last edited by mirh (2019-11-21 01:38:18)

Offline

#241 2019-11-30 19:29:51

maximbaz
Package Maintainer (PM)
Registered: 2017-12-28
Posts: 54

Re: chromium: hardware video acceleration with VA-API

Just wanted to share my newest finding, enhanced-h264ify is a Chromium/Firefox extension that allows to disable specific codecs on youtube, not only "everything except h264" like h264ify does. In my case, since dav1d is not GPU accelerated but h264/vp8/vp9 all are, I chose to block AV1 codec alone.

Offline

#242 2019-12-06 12:53:25

Bram0007
Member
Registered: 2019-12-06
Posts: 1

Re: chromium: hardware video acceleration with VA-API

Hey,

I`m tryning to play stadia with my laptop. Already installed chromium with vaapi support. When i go to youtube and start a video with VP9. I see that it use "MojoVideoDecoder" driver. But when i run stadia it will fallback to: "VpxVideoDecoder".

With this i have a huge lag and i cannot play any game on my laptop from stadia.

libva info: VA-API version 1.5.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_4
libva info: va_openDriver() returns 0
.... ...
VAProfileVP9Profile0 : VAEntrypointVLD
VAProfileVP9Profile2 : VAEntrypointVLD

 ~> chromium-browser  --ignore-gpu-blacklist --disable-gpu-vsync --enable-gpu-rasterization --disable-gpu-driver-workarounds --no-sandbox
[53889:53889:1206/130600.424534:ERROR:sandbox_linux.cc(374)] InitializeSandbox() called with multiple threads in process gpu-process.
[53889:53889:1206/130600.668374:ERROR:buffer_manager.cc(488)] [.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error from previous GL command
[53891:53907:1206/130600.747534:ERROR:nss_util.cc(283)] After loading Root Certs, loaded==false: NSS error code: -8018
[54001:54001:1206/130604.794661:ERROR:child_process_sandbox_support_impl_linux.cc(79)] FontService unique font name matching request did not receive a response.
[54001:54001:1206/130606.549527:ERROR:child_process_sandbox_support_impl_linux.cc(79)] FontService unique font name matching request did not receive a response.
[54001:54001:1206/130606.551310:ERROR:child_process_sandbox_support_impl_linux.cc(79)] FontService unique font name matching request did not receive a response.
[54156:54156:1206/130619.652337:ERROR:child_process_sandbox_support_impl_linux.cc(79)] FontService unique font name matching request did not receive a response.
[54156:54156:1206/130619.704311:ERROR:child_process_sandbox_support_impl_linux.cc(79)] FontService unique font name matching request did not receive a response.
[54156:54156:1206/130619.710548:ERROR:child_process_sandbox_support_impl_linux.cc(79)] FontService unique font name matching request did not receive a response.
[54156:54202:1206/130619.996221:ERROR:internal_decoder_factory.cc(56)] Trying to create decoder for unsupported format
[54156:54202:1206/130619.997361:ERROR:internal_decoder_factory.cc(56)] Trying to create decoder for unsupported format
[54156:54202:1206/130624.312520:ERROR:internal_decoder_factory.cc(56)] Trying to create decoder for unsupported format
[54156:54202:1206/130624.315317:ERROR:internal_decoder_factory.cc(56)] Trying to create decoder for unsupported format
[54156:54201:1206/130624.922114:ERROR:data_channel.cc(53)] Accepting maxRetransmits = -1 for backwards compatibility
[54156:54201:1206/130624.922264:ERROR:data_channel.cc(58)] Accepting maxRetransmitTime = -1 for backwards compatibility
[54156:54201:1206/130630.553970:ERROR:data_channel.cc(58)] Accepting maxRetransmitTime = -1 for backwards compatibility
[54156:54202:1206/130630.587529:ERROR:internal_decoder_factory.cc(56)] Trying to create decoder for unsupported format
[54156:54202:1206/130630.590150:ERROR:internal_decoder_factory.cc(56)] Trying to create decoder for unsupported format
[54156:54202:1206/131033.777873:ERROR:internal_decoder_factory.cc(56)] Trying to create decoder for unsupported format
[54156:54202:1206/131033.779448:ERROR:internal_decoder_factory.cc(56)] Trying to create decoder for unsupported format
[54156:54202:1206/131034.073104:ERROR:internal_decoder_factory.cc(56)] Trying to create decoder for unsupported format
[54156:54202:1206/131034.074354:ERROR:internal_decoder_factory.cc(56)] Trying to create decoder for unsupported format
[54156:54201:1206/131034.687962:ERROR:data_channel.cc(53)] Accepting maxRetransmits = -1 for backwards compatibility
[54156:54201:1206/131034.688057:ERROR:data_channel.cc(58)] Accepting maxRetransmitTime = -1 for backwards compatibility
[54156:54201:1206/131035.826778:ERROR:data_channel.cc(58)] Accepting maxRetransmitTime = -1 for backwards compatibility
[54156:54202:1206/131035.835184:ERROR:internal_decoder_factory.cc(56)] Trying to create decoder for unsupported format
[54156:54202:1206/131035.836353:ERROR:internal_decoder_factory.cc(56)] Trying to create decoder for unsupported format

Offline

#243 2019-12-11 09:35:14

maximbaz
Package Maintainer (PM)
Registered: 2017-12-28
Posts: 54

Re: chromium: hardware video acceleration with VA-API

Looking for a help with updating the vaapi patch for Chromium 79, if anyone has a fixed patch, please share with me smile

../../media/gpu/vaapi/vaapi_video_decode_accelerator.cc:1099:38: error: no member named 'GetVendorStringForTesting' in 'media::VaapiWrapper'
  if (base::StartsWith(VaapiWrapper::GetVendorStringForTesting(),
                       ~~~~~~~~~~~~~~^
1 error generated.

[16857/37009] CXX obj/media/renderers/renderers/video_resource_updater.o
ninja: build stopped: subcommand failed.

Offline

#244 2019-12-11 10:39:19

liewkj
Member
Registered: 2019-07-08
Posts: 210

Re: chromium: hardware video acceleration with VA-API

Let's try this by simply adding back the implementation.

--- chromium-79.0.3945.79/media/gpu/vaapi/vaapi_wrapper.cc	2019-12-09 13:51:52.000000000 -0800
+++ ./vaapi_wrapper.cc	2019-12-11 02:28:55.172810666 -0800
@@ -1067,6 +1067,11 @@
 NativePixmapAndSizeInfo::~NativePixmapAndSizeInfo() = default;
 
 // static
+const std::string& VaapiWrapper::GetVendorStringForTesting() {
+  return VADisplayState::Get()->va_vendor_string();
+}
+
+// static
 VAImplementation VaapiWrapper::GetImplementationType() {
   return VASupportedProfiles::Get().GetImplementationType();
 }
--- chromium-79.0.3945.79/media/gpu/vaapi/vaapi_wrapper.h	2019-12-11 04:46:54.360029772 -0800
+++ ./vaapi_wrapper.h	2019-12-09 13:51:52.000000000 -0800
@@ -115,9 +115,6 @@
     bool yuv444 : 1;
   };
 
+  // Returns the VAAPI vendor string (obtained using vaQueryVendorString()).
+  static const std::string& GetVendorStringForTesting();
+
   // Returns the type of the underlying VA-API implementation.
   static VAImplementation GetImplementationType();

No sure if this would still work. As I have always said, VDPAU is a hack. Or, you can also choose to drop that completely smile

Last edited by liewkj (2019-12-11 12:51:56)

Offline

#245 2019-12-11 22:48:03

maximbaz
Package Maintainer (PM)
Registered: 2017-12-28
Posts: 54

Re: chromium: hardware video acceleration with VA-API

Thank you! I used something similar that was suggested on AUR, but will try this as well next time, it looks even shorter smile But build succeeded, everything is perfect now!

Offline

#246 2019-12-11 23:23:17

liewkj
Member
Registered: 2019-07-08
Posts: 210

Re: chromium: hardware video acceleration with VA-API

Cool! Somehow, my own build on ArchLinux box is failing with clang++ segmentation faults randomly. The same machine used to be good at building Chromium.
Is your build machine running ArchLinux?

Offline

#247 2019-12-12 09:24:54

maximbaz
Package Maintainer (PM)
Registered: 2017-12-28
Posts: 54

Re: chromium: hardware video acceleration with VA-API

It is running Arch Linux, yes, but I use quite a beefy machine, I won't be surprised if Chromium simply gets hungrier and hungrier over time, which leads to random crashes on less powerful hardware.

Offline

#248 2019-12-12 10:03:42

once
Member
From: Taiwan
Registered: 2006-09-12
Posts: 266

Re: chromium: hardware video acceleration with VA-API

does source code include Ozone patches already.

Offline

#249 2019-12-12 13:52:37

justkdng
Member
From: 日本
Registered: 2019-10-08
Posts: 46

Re: chromium: hardware video acceleration with VA-API

once wrote:

does source code include Ozone patches already.

Ozone patches were already included some versions ago, you just have to enable it in the flags.

liewkj wrote:

Cool! Somehow, my own build on ArchLinux box is failing with clang++ segmentation faults randomly. The same machine used to be good at building Chromium.
Is your build machine running ArchLinux?

You can try the openSUSE's build service, it's free and it only takes an hour and a half to finish compiling (much better than using my own box), so far so good. https://build.opensuse.org/package/show … d-chromium


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

Offline

#250 2019-12-14 01:48:50

liewkj
Member
Registered: 2019-07-08
Posts: 210

Re: chromium: hardware video acceleration with VA-API

Finally, there is good news for getting chromium-vaapi working on GNOME/Wayland for Intel Graphics smile

In summary, chromium-vaapi was plagued by 2 major issues

The XWayland vsync issue was closed out with incomplete merges. The remaining commits are moved into another merge request and still opened til today (https://gitlab.freedesktop.org/xorg/xse … quests/116), but these are the critical ones. There are 4 commits in the merge request branch from  https://gitlab.freedesktop.org/romangg/ … tFramerate

d3c644d9921efdafdc1391325d913c25d5b78158
fe193049b0d42955ae20e8dc7c5cbf493ab2308a
a0bfbb4ab5a163f12980371427940802a11c14e0
ee1bf069dd779501a05b475de4a23defc8762aff

These 4 commits resolve the flooding ERRORs "[11098:11098:1116/194704.653664:ERROR:sync_control_vsync_provider.cc(140)] Calculated bogus refresh interval..." that many have already reported when running Chromium with "--use-gl=egl" switch. Though this is not specific to chromium-vaapi.

The 2nd issue is a bug in Chromium that affects Intel i965 and iHD VA drivers, especially the i965 VA drivers which most people seems to prefer over the iHD driver and support more version of Intel Graphics from Sandybridge to the latest & greatest. However for mobile use cases, it seems that iHD VA driver is more power efficient compared to i965, based on the stats from intel_gpu_top playing back the same video locally with mpv-vaapi and gstreamer-vaapi. In Chromium, the VA-API initialization takes place before the UI/GL initialization, so the following code snippet will always take the path of gl::kGLImplementationNone.

bool VADisplayState::InitializeOnce() {
  ...
  switch (gl::GetGLImplementation()) {
    case gl::kGLImplementationEGLGLES2:
      va_display_ = vaGetDisplayDRM(drm_fd_.get());
      break;
    case gl::kGLImplementationDesktopGL:
#if defined(USE_X11)
      va_display_ = vaGetDisplay(gfx::GetXDisplay());
#else
      LOG(WARNING) << "VAAPI video acceleration not available without "
                      "DesktopGL (GLX).";
#endif  // USE_X11
      break;
    // Cannot infer platform from GL, try all available displays
    case gl::kGLImplementationNone:
#if defined(USE_X11)
      va_display_ = vaGetDisplay(gfx::GetXDisplay());
      if (vaDisplayIsValid(va_display_))
        break;
#endif  // USE_X11
      va_display_ = vaGetDisplayDRM(drm_fd_.get());
      break;

    default:
      LOG(WARNING) << "VAAPI video acceleration not available for "
                   << gl::GetGLImplementationName(gl::GetGLImplementation());
      return false;
  }
  ...
}

For i965 VA driver, vaInitialize() failed with XDisplay on XWayland due to missing DRI3 support, which is the correct behavior.
For iHD VA driver, vaInitialize() passed with XDisplay on XWayland disregarding missing DRI3 support. Later when vaPutSurface() was called, it segmentation faulted due to de-referencing NULL pointer for call that only available for XDisplay. I think this is wrong and a very bad driver bug. And it can be reproduced consistently with mpv under GNOME/Wayland and the error logged in dmesg.

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

Due to the 2nd Chromium bug, the i965 VA driver is doomed as it simply can't initialize VA-API on Wayland. The iHD driver would segmentation fault when MojoVideoDecoder was alive and Chromium would then fallback to software decoder. With "--use-gl=egl" switch, the iHD VA driver would survive from vaPutSurface(), perhaps due to Chromium EGL implementation simply assuming VA-API over DRM even though vaGetDisplayDRM() was never called with a renderNode. So the solution is to patch Chromium to honor "--use-gl=egl" during VA-API initialization and luckily it is quite an easy patch to do smile .

--- orig/chromium-79.0.3945.79/media/gpu/vaapi/vaapi_wrapper.cc 2019-12-09 13:51:52.000000000 -0800
+++ ./src/chromium-79.0.3945.79/media/gpu/vaapi/vaapi_wrapper.cc        2019-12-13 12:35:10.447302100 -0800
@@ -54,6 +54,7 @@
 #include "ui/gfx/native_pixmap_handle.h"
 #include "ui/gl/gl_bindings.h"
 #include "ui/gl/gl_implementation.h"
+#include "ui/gl/init/gl_factory.h"

 #if defined(USE_X11)
 #include <va/va_x11.h>
@@ -360,6 +364,7 @@
   if (refcount_++ > 0)
     return true;

+  gl::init::InitializeGLOneOff();
   const bool success = InitializeOnce();
   UMA_HISTOGRAM_BOOLEAN("Media.VaapiWrapper.VADisplayStateInitializeSuccess",
                         success);

With this additional patch, chromium hardware accelerated video decoding would be fully functional in Wayland with i965 VA driver using the EGL backend and VA-API over DRM. There is no need for DRI3 support from VA drivers or libva to deal with XWayland.

MESA VA drivers (r600, nouveau, radeonsi) seem to be unaffected by the 2nd Chromium issue, perhaps their vaGetDisplay()/vaInitialize() have supports for both DRI3 and DRM infrastructures in one-shot. However, Chromium behavior remains unwarranted if vaGetDisplay()/vaInitialize() only provides DRI2/DRI3 infrastructures and vaGetDisplayDRM()/vaInitialize() only provides DRM infrastructure.

Offline

Board footer

Powered by FluxBB