chromium: hardware video acceleration with VA-API

enihcam · 2019-06-19 04:59:11

For ppl who installed intel-media-driver and enabled

LIBVA_DRIVER_NAME=iHD

Could you please update mesa to 19.1 and try iHD together with the new Intel openGL driver as well?

MESA_LOADER_DRIVER_OVERRIDE=iris

CarbonChauvinist · 2019-06-19 12:59:53

enihcam wrote:

For ppl who installed intel-media-driver and enabled
LIBVA_DRIVER_NAME=iHD
Could you please update mesa to 19.1 and try iHD together with the new Intel openGL driver as well?
MESA_LOADER_DRIVER_OVERRIDE=iris

Can you expand on the impetus for this request? I realize this is the new Gallium3D driver which is for "Gen 8"+ intel graphics and is meant to be a future switch away from i965?

On my Skylake box (i5-6440HQ) with the newly updated mesa 19.1 and the intel-media-driver installed and LIBVA_DRIVER_NAME=iHD already set, I was able to run Chromium with the MESA_LOADER_DRIVER_OVERRIDE=iris just fine and HW accel still seemed to work perfectly using H264ify extension (confirmed with intel_gpu_top).

Trying to reboot with MESA_LOADER_DRIVER_OVERRIDE=iris variable set however and my desktop, wayland plasma, did not load after logging in via SDDM. Is this meant to be an application specific flag that you only pass when starting desired programs like Chromium? I didn't have time to drill down and investigate as yet but will check further when I'm back home.

--edit

Plasma's X session with MESA_LOADER_DRIVER_OVERRIDE=iris loads just fine and chromium plays hw accelerated with the intel-media-driver.

Last edited by CarbonChauvinist (2019-06-20 00:39:07)

enihcam · 2019-06-20 04:15:38

CarbonChauvinist wrote:

enihcam wrote:
For ppl who installed intel-media-driver and enabled
LIBVA_DRIVER_NAME=iHD
Could you please update mesa to 19.1 and try iHD together with the new Intel openGL driver as well?
MESA_LOADER_DRIVER_OVERRIDE=iris
Can you expand on the impetus for this request? I realize this is the new Gallium3D driver which is for "Gen 8"+ intel graphics and is meant to be a future switch away from i965?
On my Skylake box (i5-6440HQ) with the newly updated mesa 19.1 and the intel-media-driver installed and LIBVA_DRIVER_NAME=iHD already set, I was able to run Chromium with the MESA_LOADER_DRIVER_OVERRIDE=iris just fine and HW accel still seemed to work perfectly using H264ify extension (confirmed with intel_gpu_top).
Trying to reboot with MESA_LOADER_DRIVER_OVERRIDE=iris variable set however and my desktop, wayland plasma, did not load after logging in via SDDM. Is this meant to be an application specific flag that you only pass when starting desired programs like Chromium? I didn't have time to drill down and investigate as yet but will check further when I'm back home.
--edit
Plasma's X session with MESA_LOADER_DRIVER_OVERRIDE=iris loads just fine and chromium plays hw accelerated with the intel-media-driver.

This flag should not be application specific. I was just guessing the iris driver might mitigate the situation. I was wrong.

maximbaz · 2019-06-21 13:57:31

I have learned today that we don't need to patch Chromium sources to get VA-API support, an interesting alternative is to simply compile Chromium with `use_vaapi=true` flag and `libva` as a dependency, and then VA-API stays disabled by default, but users can enable it on case-by-case basis using `--ignore-gpu-blacklist`.

I think this is something we should consider doing for `extra/chromium`, it would make HW acceleration much more accessible to end-users, and yet stay disabled by default so we don't suddenly break video playback for some users.

digitalone · 2019-06-21 16:49:25

maximbaz wrote:

I have learned today that we don't need to patch Chromium sources to get VA-API support, an interesting alternative is to simply compile Chromium with `use_vaapi=true` flag and `libva` as a dependency, and then VA-API stays disabled by default, but users can enable it on case-by-case basis using `--ignore-gpu-blacklist`.
I think this is something we should consider doing for `extra/chromium`, it would make HW acceleration much more accessible to end-users, and yet stay disabled by default so we don't suddenly break video playback for some users.

Wow, this is very interesting!

akarshanbiswas · 2019-06-22 03:42:44

@maximbaz Hi. They are now blocking us to allow build chromium with vaapi support. https://github.com/chromium/chromium/co … 16b182967c

commit queue is here: https://chromium-review.googlesource.co … /+/1657877

edit: Looking at the commit list, they haven't removed support for vaapi yet, they removed dmabuf video frame mapper and platform frame utils from linux.

Last edited by akarshanbiswas (2019-06-22 05:04:51)

afader · 2019-06-22 16:58:05

I had to downgrade to chromium-vaapi-bin 72 for my nvidia gtx 970 hwaccel because any newer version uses Ffmpeg decoder instead of Mojo or Gpu. Is there a way we can compile to use system ffmpeg where i have nvdec support? Alternatively, if we can compile regular chromium with vaapi why doesn't it work anymore?

goyis1000 · 2019-06-23 03:25:27

afader wrote:

I had to downgrade to chromium-vaapi-bin 72 for my nvidia gtx 970 hwaccel because any newer version uses Ffmpeg decoder instead of Mojo or Gpu. Is there a way we can compile to use system ffmpeg where i have nvdec support? Alternatively, if we can compile regular chromium with vaapi why doesn't it work anymore?

The same happens on my side, I have an old but good nvidia GT210 for my current purposes and I can only get hw accel video with an old version of chromium. I installed chromium-vaapi-bin, tried all kind of flags and ffmpeg gets used for video decoding not matter what. It will be good if someones compile a static version because of the shared libraries getting updates and messing up chromium 72 or even better we must find a workaround to fix this, but I think I will take a lot of time and effort because of the problems that all we know

xuanrui · 2019-06-24 09:11:42

Same happens to me. I'm forced to disable HW acceleration for the moment. I'm also using NVIDIA hardware (GTX 1050 Mobile).

There are also reports from Intel graphics users that the integrated Intel GPUs are also not working with latest Chromium.

mbrennr · 2019-06-24 22:15:55

Anybody looked at the output of chrome://media-internals ? There's a log in there, like so:

0:00:00.000	origin_url	https://www.youtube.com/
00:00:00.000	frame_url	https://www.youtube.com/watch?v=lfqpp3xY1d8
00:00:00.000	frame_title	Wayne Rainey's MotoAmerica YZF-R1 Custom - Jay Leno’s Garage - YouTube
00:00:00.000	surface_layer_mode	kOnDemand
00:00:00.000	url	blob:https://www.youtube.com/36415451-ee81-46b9-a0bb-f8d7ff46f998
00:00:00.061	info	ChunkDemuxer: buffering by DTS
00:00:00.077	pipeline_state	kStarting
00:00:00.479	found_audio_stream	true
00:00:00.479	audio_codec_name	aac
00:00:00.875	found_video_stream	true
00:00:00.875	video_codec_name	h264
00:00:00.226	duration	1370
00:00:01.147	audio_dds	false
00:00:01.147	audio_decoder	FFmpegAudioDecoder
00:00:01.147	is_platform_audio_decoder	false
00:00:01.147	info	Selected FFmpegAudioDecoder for audio decoding, config: codec: aac, bytes_per_channel: 2, channel_layout: 3, channels: 2, samples_per_second: 44100, sample_format: 2, bytes_per_frame: 4, seek_preroll: 0us, codec_delay: 0, has extra data: false, encryption scheme: Unencrypted, discard decoder delay: false
00:00:01.242	video_dds	false
00:00:01.242	video_decoder	MojoVideoDecoder
00:00:01.242	is_platform_video_decoder	true
00:00:01.242	info	Selected MojoVideoDecoder for video decoding, config: codec: h264, format: PIXEL_FORMAT_I420, profile: h264 main, coded size: [1280,720], visible rect: [0,0,1280,720], natural size: [1280,720], has extra data: false, encryption scheme: Unencrypted, rotation: 0°
00:00:01.242	pipeline_state	kPlaying
00:00:01.308	audio_buffering_state	BUFFERING_HAVE_ENOUGH
00:00:01.332	error	VDA Error 4
00:00:01.359	video_dds	false
00:00:01.359	video_decoder	FFmpegVideoDecoder
00:00:01.359	is_platform_video_decoder	false
00:00:01.359	info	Selected FFmpegVideoDecoder for video decoding, config: codec: h264, format: PIXEL_FORMAT_I420, profile: h264 main, coded size: [1280,720], visible rect: [0,0,1280,720], natural size: [1280,720], has extra data: false, encryption scheme: Unencrypted, rotation: 0°
00:00:01.464	height	720
00:00:01.464	width	1280
00:00:01.584	video_buffering_state	BUFFERING_HAVE_ENOUGH
00:00:01.584	for_suspended_start	false
00:00:01.584	pipeline_buffering_state	BUFFERING_HAVE_ENOUGH
00:00:01.584	info	Effective playback rate changed from 0 to 1
00:00:01.585	event	PLAY
00:00:00.993	duration	1369.582585
00:00:02.114	video_buffering_state	BUFFERING_HAVE_NOTHING
00:00:02.211	video_buffering_state	BUFFERING_HAVE_ENOUGH
00:00:03.258	video_buffering_state	BUFFERING_HAVE_NOTHING
00:00:03.752	video_buffering_state	BUFFERING_HAVE_ENOUGH
00:00:13.485	info	Selected video track: []
00:00:13.494	video_buffering_state	BUFFERING_HAVE_NOTHING
00:00:13.497	video_buffering_state	BUFFERING_HAVE_ENOUGH
00:00:13.497	for_suspended_start	false
00:00:13.497	pipeline_buffering_state	BUFFERING_HAVE_ENOUGH

It selects mojovideo first, gets an VDA Error 4 at 0:00:01.332 and then falls back to ffmpeg.

And vainfo:

vainfo: VA-API version: 1.4 (libva 2.4.1)
vainfo: Driver version: Splitted-Desktop Systems VDPAU backend for VA-API - 0.7.4
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileMPEG4Simple            : VAEntrypointVLD
      VAProfileMPEG4AdvancedSimple    : VAEntrypointVLD
      <unknown profile>               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointVLD
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD

I think the <unknown profile> "confuses" chromium and causes the "VDA Error 4".
That's why I flagged libva-vdpau-driver-chromium out of date in the AUR.

This is with Chromium (Vaapi-bin) 74.0.3729.169.

Article about Hardware Video Acceleration in archwiki mentions different packages for translation layers, remember what you're trying to do.
libva-vdpau-driver: You have vdpau in the driver, but no VAAPI, Need to translate VAAPI calls to vdpau, this applies to nvidia proprietary driver.

The patched libva-vdpau-driver-chromium in the AUR worked for a while, but either chromium or nvidia, or both, changed something, so now it doesn't work anymore.

So, how do we fix this?

xuanrui · 2019-06-25 01:29:16

It seems that, for NVIDIA users, libva-vdpau-driver-chromium needs to be updated.

goyis1000 · 2019-06-25 04:21:57

mbrennr wrote:

Anybody looked at the output of chrome://media-internals ? There's a log in there, like so:

0:00:00.000	origin_url	https://www.youtube.com/
00:00:00.000	frame_url	https://www.youtube.com/watch?v=lfqpp3xY1d8
00:00:00.000	frame_title	Wayne Rainey's MotoAmerica YZF-R1 Custom - Jay Leno’s Garage - YouTube
00:00:00.000	surface_layer_mode	kOnDemand
00:00:00.000	url	blob:https://www.youtube.com/36415451-ee81-46b9-a0bb-f8d7ff46f998
00:00:00.061	info	ChunkDemuxer: buffering by DTS
00:00:00.077	pipeline_state	kStarting
00:00:00.479	found_audio_stream	true
00:00:00.479	audio_codec_name	aac
00:00:00.875	found_video_stream	true
00:00:00.875	video_codec_name	h264
00:00:00.226	duration	1370
00:00:01.147	audio_dds	false
00:00:01.147	audio_decoder	FFmpegAudioDecoder
00:00:01.147	is_platform_audio_decoder	false
00:00:01.147	info	Selected FFmpegAudioDecoder for audio decoding, config: codec: aac, bytes_per_channel: 2, channel_layout: 3, channels: 2, samples_per_second: 44100, sample_format: 2, bytes_per_frame: 4, seek_preroll: 0us, codec_delay: 0, has extra data: false, encryption scheme: Unencrypted, discard decoder delay: false
00:00:01.242	video_dds	false
00:00:01.242	video_decoder	MojoVideoDecoder
00:00:01.242	is_platform_video_decoder	true
00:00:01.242	info	Selected MojoVideoDecoder for video decoding, config: codec: h264, format: PIXEL_FORMAT_I420, profile: h264 main, coded size: [1280,720], visible rect: [0,0,1280,720], natural size: [1280,720], has extra data: false, encryption scheme: Unencrypted, rotation: 0°
00:00:01.242	pipeline_state	kPlaying
00:00:01.308	audio_buffering_state	BUFFERING_HAVE_ENOUGH
00:00:01.332	error	VDA Error 4
00:00:01.359	video_dds	false
00:00:01.359	video_decoder	FFmpegVideoDecoder
00:00:01.359	is_platform_video_decoder	false
00:00:01.359	info	Selected FFmpegVideoDecoder for video decoding, config: codec: h264, format: PIXEL_FORMAT_I420, profile: h264 main, coded size: [1280,720], visible rect: [0,0,1280,720], natural size: [1280,720], has extra data: false, encryption scheme: Unencrypted, rotation: 0°
00:00:01.464	height	720
00:00:01.464	width	1280
00:00:01.584	video_buffering_state	BUFFERING_HAVE_ENOUGH
00:00:01.584	for_suspended_start	false
00:00:01.584	pipeline_buffering_state	BUFFERING_HAVE_ENOUGH
00:00:01.584	info	Effective playback rate changed from 0 to 1
00:00:01.585	event	PLAY
00:00:00.993	duration	1369.582585
00:00:02.114	video_buffering_state	BUFFERING_HAVE_NOTHING
00:00:02.211	video_buffering_state	BUFFERING_HAVE_ENOUGH
00:00:03.258	video_buffering_state	BUFFERING_HAVE_NOTHING
00:00:03.752	video_buffering_state	BUFFERING_HAVE_ENOUGH
00:00:13.485	info	Selected video track: []
00:00:13.494	video_buffering_state	BUFFERING_HAVE_NOTHING
00:00:13.497	video_buffering_state	BUFFERING_HAVE_ENOUGH
00:00:13.497	for_suspended_start	false
00:00:13.497	pipeline_buffering_state	BUFFERING_HAVE_ENOUGH

It selects mojovideo first, gets an VDA Error 4 at 0:00:01.332 and then falls back to ffmpeg.

And vainfo:

vainfo: VA-API version: 1.4 (libva 2.4.1)
vainfo: Driver version: Splitted-Desktop Systems VDPAU backend for VA-API - 0.7.4
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileMPEG4Simple            : VAEntrypointVLD
      VAProfileMPEG4AdvancedSimple    : VAEntrypointVLD
      <unknown profile>               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointVLD
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD

I think the <unknown profile> "confuses" chromium and causes the "VDA Error 4".
That's why I flagged libva-vdpau-driver-chromium out of date in the AUR.

This is with Chromium (Vaapi-bin) 74.0.3729.169.

Article about Hardware Video Acceleration in archwiki mentions different packages for translation layers, remember what you're trying to do.
libva-vdpau-driver: You have vdpau in the driver, but no VAAPI, Need to translate VAAPI calls to vdpau, this applies to nvidia proprietary driver.

The patched libva-vdpau-driver-chromium in the AUR worked for a while, but either chromium or nvidia, or both, changed something, so now it doesn't work anymore.

So, how do we fix this?

I don't think that the backend of vdapau to vaapi for chromium is the main problem because, I tried different versions of chromium and also the problem with nvidia hw decoding starts in v73 before vaapi were removed.

I have a Geforce 210, the driver that I use is nvidia-340xx and that specific driver not were updated in a lot of time so the driver is probably not the problem.
Also I dont get that <unknown profile> in vainfo and still the hw accel don't work see my output:

lspci
VGA compatible controller: NVIDIA Corporation GT218 [GeForce 210] (rev a2)

vainfo: VA-API version: 1.4 (libva 2.4.1)
vainfo: Driver version: Splitted-Desktop Systems VDPAU backend for VA-API - 0.7.4
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileMPEG4Simple            : VAEntrypointVLD
      VAProfileMPEG4AdvancedSimple    : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointVLD
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD

So apparently the problem resides in chromium, also in the latest version of chromium-vaapi-bin I am getting some errors that in previous versions not were present maybe related to the VDA Error 4 that I also see in chrome://media-internals.

chromium
[27207:27207:0624/233543.164857:ERROR:vaapi_wrapper.cc(441)] GetConfigAttributes failed for va_profile 6
[27207:27207:0624/233543.165000:ERROR:vaapi_wrapper.cc(441)] GetConfigAttributes failed for va_profile 7

Last edited by goyis1000 (2019-06-25 04:39:40)

afader · 2019-06-25 05:02:42

Looking here https://aur.archlinux.org/cgit/aur.git/ … 616b7bdac1

++    vdp_profile = get_VdpDecoderProfile(obj_config->profile);
++    if (!get_max_surface_size(driver_data, vdp_profile, &max_width, &max_height))
++        return VA_STATUS_ERROR_UNSUPPORTED_PROFILE;

Anyone know how i could use gdb or something to hook into this?

xuanrui · 2019-06-27 10:41:59

afader wrote:

Looking here https://aur.archlinux.org/cgit/aur.git/ … 616b7bdac1
++    vdp_profile = get_VdpDecoderProfile(obj_config->profile);
++    if (!get_max_surface_size(driver_data, vdp_profile, &max_width, &max_height))
++        return VA_STATUS_ERROR_UNSUPPORTED_PROFILE;
Anyone know how i could use gdb or something to hook into this?

I suppose you can build the package with debug options, find the patched line in the code, set a breakpoint there and then trace execution. It would be complicated but (maybe, just maybe) not too difficult if you are a good systems programmer. In any case, we should keep in touch with the maintainer of libva-vdpau-driver-chromium who seems AWOL at the moment.

goyis1000 · 2019-06-27 21:50:09

Hello again.
I searched all over the web and apparently someone already fixed the problem with nvidia hw accel in chromium vaapi on ubuntu see this: https://github.com/saiarcot895/chromium … /issues/42 unfortunately patches are not shared, at least in the closed issue, maybe if we contact saiarcot895 he will share the patch for also fix this issue on arch linux. The only useful info in there is that the problem probably is related to this commit of chromium https://chromium.googlesource.com/chrom … 977dd5727d so like I thought the problem is in the wrapper of vaapi on chromium. Also if we use the flag --disable-features=MojoVideoDecoder in chromium the vda error 4 dissapears in the log but the hw accel still not works.

Last edited by goyis1000 (2019-06-27 21:59:41)

goyis1000 · 2019-06-27 22:31:07

I finally found the patches for fix nvidia hw decoding, someone test them for build chromium, the patches are in this commit https://github.com/saiarcot895/chromium … 5ee4bc789c

goyis1000 · 2019-06-28 00:17:43

I used debtap to test the version of chromium for ubuntu with the patches and it worked!! the nvidia hw accel can be fixed just use the patches that I mention in my comment. Special thanks to saiarcot895 for take the time to fix this, that certainly will help a lot of NVIDIA users.

Last edited by goyis1000 (2019-06-28 01:42:36)

akarshanbiswas · 2019-06-28 09:05:08

I have prepared a patch from saiarcot895 that can be added to the existing vaapi patch that arch and other uses. Need testing BTW.
https://pastebin.com/VZYH0NPR

afader · 2019-06-28 23:17:38

Tried to compile chromium-vaapi with the patch and got this error

../../chrome/browser/ui/tabs/tab_strip_model_observer.cc:77:22: error: defaulting this default constructor would delete it after its first declaration
TabStripModelChange::TabStripModelChange() = default;
                     ^
../../chrome/browser/ui/tabs/tab_strip_model_observer.h:138:28: note: default constructor of 'TabStripModelChange' is implicitly deleted because field 'deltas_' of const-qualified type 'const std::vector<Delta>' would not be initialized
  const std::vector<Delta> deltas_;
                           ^
1 error generated.
[21991/34721] CXX obj/chrome/browser/ui/ui/tab_strip_model.o
ninja: build stopped: subcommand failed.
==> ERROR: A failure occurred in build().

Edit: Nevermind, I need to update libstdc++

Last edited by afader (2019-06-28 23:27:19)

jpegxguy · 2019-06-29 02:13:35

@maximbaz, in your pkgbuild.com repo, chromium-vaapi is stuck at 74.0.3729.169-2 in the .db files, even though newer versions are actually available in the repo. Had to install manually. Might also affect other packages

Last edited by jpegxguy (2019-06-29 02:14:02)

afader · 2019-06-29 20:40:06

I can't get it to work, I get a lot of weird compile errors that i don't get normally. Anyone else able to compile with patch?

akarshanbiswas · 2019-06-30 04:11:40

@afader What weird compile errors are you facing?

For the first error, just remove the 'const' from `const std::vector<Delta> deltas_;`.

maximbaz · 2019-06-30 07:53:58

@jpegxguy, thanks for the ping, this is on purpose - chromium 74 is the last version where HW acceleration works on my own integrated Intel GPU, so I keep that one in my repo, even though I've compiled a couple of v75 builds just to test HW acceleration and allow folks from chromium-vaapi-bin to test the builds as well.

Forgot to reply sooner, `MESA_LOADER_DRIVER_OVERRIDE=iris` sadly doesn't help with chromium 75.

afader · 2019-06-30 19:31:01

../../cc/scheduler/compositor_frame_reporting_controller.cc:34:3: error: no matching function for call to 'MakeCheckOpValueString'
  DCHECK_NE(reporters_[PipelineStage::kBeginMainFrame],
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../base/logging.h:940:31: note: expanded from macro 'DCHECK_NE'
#define DCHECK_NE(val1, val2) DCHECK_OP(NE, !=, val1, val2)
                              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../base/logging.h:913:29: note: expanded from macro 'DCHECK_OP'
                            ::logging::MakeCheckOpValueString(      \
                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../base/logging.h:724:18: note: candidate function not viable: no known conversion from 'std::unique_ptr<CompositorFrameReporter>' to 'std::nullptr_t' (aka 'nullptr_t') for 2nd argument
BASE_EXPORT void MakeCheckOpValueString(std::ostream* os, std::nullptr_t p);
                 ^
../../base/logging.h:695:1: note: candidate template ignored: requirement 'base::internal::SupportsOstreamOperator<const std::unique_ptr<cc::CompositorFrameReporter, std::default_delete<cc::CompositorFrameReporter> > &, void>::value' was not satisfied [with T = std::unique_ptr<cc::CompositorFrameReporter, std::default_delete<cc::CompositorFrameReporter> >]
MakeCheckOpValueString(std::ostream* os, const T& v) {
^
../../base/logging.h:708:1: note: candidate template ignored: requirement 'std::is_function<std::unique_ptr<cc::CompositorFrameReporter, std::default_delete<cc::CompositorFrameReporter> > >::value' was not satisfied [with T = std::unique_ptr<cc::CompositorFrameReporter, std::default_delete<cc::CompositorFrameReporter> >]
MakeCheckOpValueString(std::ostream* os, const T& v) {
^
../../base/logging.h:719:1: note: candidate template ignored: requirement 'std::is_enum<std::unique_ptr<cc::CompositorFrameReporter, std::default_delete<cc::CompositorFrameReporter> > >::value' was not satisfied [with T = std::unique_ptr<cc::CompositorFrameReporter, std::default_delete<cc::CompositorFrameReporter> >]
MakeCheckOpValueString(std::ostream* os, const T& v) {
^
2 errors generated.
[6/20407] CXX obj/cc/cc/eviction_tile_priority_queue.o
ninja: build stopped: subcommand failed.
==> ERROR: A failure occurred in build().
    Aborting...

xuanrui · 2019-07-03 11:10:55

Any updates?

Arch Linux

#76 2019-06-19 04:59:11

Re: chromium: hardware video acceleration with VA-API

#77 2019-06-19 12:59:53

Re: chromium: hardware video acceleration with VA-API

#78 2019-06-20 04:15:38

Re: chromium: hardware video acceleration with VA-API

#79 2019-06-21 13:57:31

Re: chromium: hardware video acceleration with VA-API

#80 2019-06-21 16:49:25

Re: chromium: hardware video acceleration with VA-API

#81 2019-06-22 03:42:44

Re: chromium: hardware video acceleration with VA-API

#82 2019-06-22 16:58:05

Re: chromium: hardware video acceleration with VA-API

#83 2019-06-23 03:25:27

Re: chromium: hardware video acceleration with VA-API

#84 2019-06-24 09:11:42

Re: chromium: hardware video acceleration with VA-API

#85 2019-06-24 22:15:55

Re: chromium: hardware video acceleration with VA-API

#86 2019-06-25 01:29:16

Re: chromium: hardware video acceleration with VA-API

#87 2019-06-25 04:21:57

Re: chromium: hardware video acceleration with VA-API

#88 2019-06-25 05:02:42

Re: chromium: hardware video acceleration with VA-API

#89 2019-06-27 10:41:59

Re: chromium: hardware video acceleration with VA-API

#90 2019-06-27 21:50:09

Re: chromium: hardware video acceleration with VA-API

#91 2019-06-27 22:31:07

Re: chromium: hardware video acceleration with VA-API

#92 2019-06-28 00:17:43

Re: chromium: hardware video acceleration with VA-API

#93 2019-06-28 09:05:08

Re: chromium: hardware video acceleration with VA-API

#94 2019-06-28 23:17:38

Re: chromium: hardware video acceleration with VA-API

#95 2019-06-29 02:13:35

Re: chromium: hardware video acceleration with VA-API

#96 2019-06-29 20:40:06

Re: chromium: hardware video acceleration with VA-API

#97 2019-06-30 04:11:40

Re: chromium: hardware video acceleration with VA-API

#98 2019-06-30 07:53:58

Re: chromium: hardware video acceleration with VA-API

#99 2019-06-30 19:31:01

Re: chromium: hardware video acceleration with VA-API

#100 2019-07-03 11:10:55

Re: chromium: hardware video acceleration with VA-API

Board footer