chromium: hardware video acceleration with VA-API

sjk132 · 2019-03-13 18:23:43

The new chromium 73.0.3683.75-1 update broke vaapi. No video playback with error

 GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error from previous GL command

downgrading to 72.0.3626.121-1 make the vaapi works again.

Graphics Feature Status
Canvas: Hardware accelerated
Flash: Hardware accelerated
Flash Stage3D: Hardware accelerated
Flash Stage3D Baseline profile: Hardware accelerated
Compositing: Hardware accelerated
Multiple Raster Threads: Enabled
Native GpuMemoryBuffers: Software only. Hardware acceleration disabled
Out-of-process Rasterization: Hardware accelerated
Hardware Protected Video Decode: Hardware accelerated
Rasterization: Hardware accelerated
Skia Renderer: Disabled
Surface Control: Disabled
Surface Synchronization: Enabled
Video Decode: Hardware accelerated
Viz Service Display Compositor: Enabled
WebGL: Hardware accelerated
WebGL2: Hardware accelerated
Driver Bug Workarounds
adjust_src_dst_region_for_blitframebuffer
clear_uniforms_before_first_program_use
count_all_in_varyings_packing
disable_framebuffer_cmaa
disable_post_sub_buffers_for_onscreen_surfaces
exit_on_context_lost
msaa_is_slow
scalarize_vec_and_mat_constructor_args
disabled_extension_GL_KHR_blend_equation_advanced
disabled_extension_GL_KHR_blend_equation_advanced_coherent
Problems Detected
Clear uniforms before first program use on all platforms: 124764, 349137
Applied Workarounds: clear_uniforms_before_first_program_use
Mesa drivers in Linux handle varyings without static use incorrectly: 333885
Applied Workarounds: count_all_in_varyings_packing
Disable partial swaps on Mesa drivers (detected with GL_RENDERER): 339493
Applied Workarounds: disable_post_sub_buffers_for_onscreen_surfaces
Always rewrite vec/mat constructors to be consistent: 398694
Applied Workarounds: scalarize_vec_and_mat_constructor_args
On Intel GPUs MSAA performance is not acceptable for GPU rasterization: 527565
Applied Workarounds: msaa_is_slow
Use GL_INTEL_framebuffer_CMAA on ChromeOS: 535198
Applied Workarounds: disable_framebuffer_cmaa
Disable partial swaps on Mesa drivers (detected with GL_VERSION): 339493
Applied Workarounds: disable_post_sub_buffers_for_onscreen_surfaces
adjust src/dst region if blitting pixels outside read framebuffer on Linux Intel: 664740
Applied Workarounds: adjust_src_dst_region_for_blitframebuffer
Disable KHR_blend_equation_advanced until cc shaders are updated: 661715
Applied Workarounds: disable(GL_KHR_blend_equation_advanced), disable(GL_KHR_blend_equation_advanced_coherent)
Some drivers can't recover after OUT_OF_MEM and context lost: 893177
Applied Workarounds: exit_on_context_lost
Native GpuMemoryBuffers have been disabled, either via about:flags or command line.
Disabled Features: native_gpu_memory_buffers
Skia renderer is not used by default.
Disabled Features: skia_renderer
Version Information
Data exported	2019-03-13T18:21:01.521Z
Chrome version	Chrome/73.0.3683.75
Operating system	Linux 5.0.0-arch1-1-ARCH
Software rendering list URL	https://chromium.googlesource.com/chromium/src/+/909ee014fcea6828f9a610e6716145bc0b3ebf4a/gpu/config/software_rendering_list.json
Driver bug list URL	https://chromium.googlesource.com/chromium/src/+/909ee014fcea6828f9a610e6716145bc0b3ebf4a/gpu/config/gpu_driver_bug_list.json
ANGLE commit id	unknown hash
2D graphics backend	Skia/73 2c36ee834ae04d036363cd3b8f3f33ec65d657f0-
Command Line	/usr/lib/chromium/chromium --flag-switches-begin --enable-gpu-rasterization --enable-oop-rasterization --enable-zero-copy --ignore-gpu-blacklist --enable-features=VizDisplayCompositor --flag-switches-end
Driver Information
Initialization time	44
In-process GPU	false
Passthrough Command Decoder	false
Sandboxed	false
GPU0	VENDOR = 0x8086 [Intel Open Source Technology Center], DEVICE= 0x591b [Mesa DRI Intel(R) HD Graphics 630 (Kaby Lake GT2) ] *ACTIVE*
Optimus	false
AMD switchable	false
Driver vendor	Mesa
Driver version	18.3.4
Driver date	
GPU CUDA compute capability major version	0
Pixel shader version	4.50
Vertex shader version	4.50
Max. MSAA samples	16
Machine model name	
Machine model version	
GL_VENDOR	Intel Open Source Technology Center
GL_RENDERER	Mesa DRI Intel(R) HD Graphics 630 (Kaby Lake GT2)
GL_VERSION	4.5 (Core Profile) Mesa 18.3.4
GL_EXTENSIONS	GL_3DFX_texture_compression_FXT1 GL_AMD_conservative_depth GL_AMD_depth_clamp_separate GL_AMD_draw_buffers_blend GL_AMD_gpu_shader_int64 GL_AMD_multi_draw_indirect GL_AMD_query_buffer_object GL_AMD_seamless_cubemap_per_texture GL_AMD_shader_stencil_export GL_AMD_shader_trinary_minmax GL_AMD_vertex_shader_layer GL_AMD_vertex_shader_viewport_index GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_APPLE_object_purgeable GL_ARB_ES2_compatibility GL_ARB_ES3_1_compatibility GL_ARB_ES3_2_compatibility GL_ARB_ES3_compatibility GL_ARB_arrays_of_arrays GL_ARB_base_instance GL_ARB_blend_func_extended GL_ARB_buffer_storage GL_ARB_clear_buffer_object GL_ARB_clear_texture GL_ARB_clip_control GL_ARB_compressed_texture_pixel_storage GL_ARB_compute_shader GL_ARB_conditional_render_inverted GL_ARB_conservative_depth GL_ARB_copy_buffer GL_ARB_copy_image GL_ARB_cull_distance GL_ARB_debug_output GL_ARB_depth_buffer_float GL_ARB_depth_clamp GL_ARB_derivative_control GL_ARB_direct_state_access GL_ARB_draw_buffers GL_ARB_draw_buffers_blend GL_ARB_draw_elements_base_vertex GL_ARB_draw_indirect GL_ARB_draw_instanced GL_ARB_enhanced_layouts GL_ARB_explicit_attrib_location GL_ARB_explicit_uniform_location GL_ARB_fragment_coord_conventions GL_ARB_fragment_layer_viewport GL_ARB_fragment_shader GL_ARB_fragment_shader_interlock GL_ARB_framebuffer_no_attachments GL_ARB_framebuffer_object GL_ARB_framebuffer_sRGB GL_ARB_get_program_binary GL_ARB_get_texture_sub_image GL_ARB_gpu_shader5 GL_ARB_gpu_shader_fp64 GL_ARB_gpu_shader_int64 GL_ARB_half_float_pixel GL_ARB_half_float_vertex GL_ARB_indirect_parameters GL_ARB_instanced_arrays GL_ARB_internalformat_query GL_ARB_internalformat_query2 GL_ARB_invalidate_subdata GL_ARB_map_buffer_alignment GL_ARB_map_buffer_range GL_ARB_multi_bind GL_ARB_multi_draw_indirect GL_ARB_occlusion_query2 GL_ARB_pipeline_statistics_query GL_ARB_pixel_buffer_object GL_ARB_point_sprite GL_ARB_polygon_offset_clamp GL_ARB_post_depth_coverage GL_ARB_program_interface_query GL_ARB_provoking_vertex GL_ARB_query_buffer_object GL_ARB_robust_buffer_access_behavior GL_ARB_robustness GL_ARB_sample_shading GL_ARB_sampler_objects GL_ARB_seamless_cube_map GL_ARB_seamless_cubemap_per_texture GL_ARB_separate_shader_objects GL_ARB_shader_atomic_counter_ops GL_ARB_shader_atomic_counters GL_ARB_shader_ballot GL_ARB_shader_bit_encoding GL_ARB_shader_clock GL_ARB_shader_draw_parameters GL_ARB_shader_group_vote GL_ARB_shader_image_load_store GL_ARB_shader_image_size GL_ARB_shader_objects GL_ARB_shader_precision GL_ARB_shader_stencil_export GL_ARB_shader_storage_buffer_object GL_ARB_shader_subroutine GL_ARB_shader_texture_image_samples GL_ARB_shader_texture_lod GL_ARB_shader_viewport_layer_array GL_ARB_shading_language_420pack GL_ARB_shading_language_packing GL_ARB_stencil_texturing GL_ARB_sync GL_ARB_tessellation_shader GL_ARB_texture_barrier GL_ARB_texture_buffer_object GL_ARB_texture_buffer_object_rgb32 GL_ARB_texture_buffer_range GL_ARB_texture_compression_bptc GL_ARB_texture_compression_rgtc GL_ARB_texture_cube_map_array GL_ARB_texture_filter_anisotropic GL_ARB_texture_float GL_ARB_texture_gather GL_ARB_texture_mirror_clamp_to_edge GL_ARB_texture_multisample GL_ARB_texture_non_power_of_two GL_ARB_texture_query_levels GL_ARB_texture_query_lod GL_ARB_texture_rectangle GL_ARB_texture_rg GL_ARB_texture_rgb10_a2ui GL_ARB_texture_stencil8 GL_ARB_texture_storage GL_ARB_texture_storage_multisample GL_ARB_texture_swizzle GL_ARB_texture_view GL_ARB_timer_query GL_ARB_transform_feedback2 GL_ARB_transform_feedback3 GL_ARB_transform_feedback_instanced GL_ARB_transform_feedback_overflow_query GL_ARB_uniform_buffer_object GL_ARB_vertex_array_bgra GL_ARB_vertex_array_object GL_ARB_vertex_attrib_64bit GL_ARB_vertex_attrib_binding GL_ARB_vertex_buffer_object GL_ARB_vertex_shader GL_ARB_vertex_type_10f_11f_11f_rev GL_ARB_vertex_type_2_10_10_10_rev GL_ARB_viewport_array GL_ATI_blend_equation_separate GL_ATI_texture_float GL_EXT_abgr GL_EXT_blend_equation_separate GL_EXT_draw_buffers2 GL_EXT_draw_instanced GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_framebuffer_multisample_blit_scaled GL_EXT_framebuffer_object GL_EXT_framebuffer_sRGB GL_EXT_packed_depth_stencil GL_EXT_packed_float GL_EXT_pixel_buffer_object GL_EXT_polygon_offset_clamp GL_EXT_provoking_vertex GL_EXT_shader_framebuffer_fetch GL_EXT_shader_framebuffer_fetch_non_coherent GL_EXT_shader_integer_mix GL_EXT_shader_samples_identical GL_EXT_texture_array GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_rgtc GL_EXT_texture_compression_s3tc GL_EXT_texture_filter_anisotropic GL_EXT_texture_integer GL_EXT_texture_sRGB GL_EXT_texture_sRGB_decode GL_EXT_texture_shared_exponent GL_EXT_texture_snorm GL_EXT_texture_swizzle GL_EXT_timer_query GL_EXT_transform_feedback GL_EXT_vertex_array_bgra GL_EXT_vertex_attrib_64bit GL_IBM_multimode_draw_arrays GL_INTEL_conservative_rasterization GL_INTEL_performance_query GL_INTEL_shader_atomic_float_minmax GL_KHR_blend_equation_advanced GL_KHR_blend_equation_advanced_coherent GL_KHR_context_flush_control GL_KHR_debug GL_KHR_no_error GL_KHR_robust_buffer_access_behavior GL_KHR_robustness GL_KHR_texture_compression_astc_ldr GL_KHR_texture_compression_astc_sliced_3d GL_MESA_pack_invert GL_MESA_shader_integer_functions GL_MESA_texture_signed_rgba GL_NV_conditional_render GL_NV_depth_clamp GL_NV_fragment_shader_interlock GL_NV_packed_depth_stencil GL_NV_texture_barrier GL_OES_EGL_image GL_S3_s3tc
Disabled Extensions	GL_KHR_blend_equation_advanced GL_KHR_blend_equation_advanced_coherent
Disabled WebGL Extensions	
Window system binding vendor	SGI
Window system binding version	1.4
Window system binding extensions	GLX_ARB_create_context GLX_ARB_create_context_no_error GLX_ARB_create_context_profile GLX_ARB_create_context_robustness GLX_ARB_fbconfig_float GLX_ARB_framebuffer_sRGB GLX_ARB_multisample GLX_EXT_create_context_es_profile GLX_EXT_create_context_es2_profile GLX_EXT_fbconfig_packed_float GLX_EXT_framebuffer_sRGB GLX_EXT_import_context GLX_EXT_libglvnd GLX_EXT_no_config_context GLX_EXT_texture_from_pixmap GLX_EXT_visual_info GLX_EXT_visual_rating GLX_MESA_copy_sub_buffer GLX_OML_swap_method GLX_SGI_make_current_read GLX_SGI_swap_control GLX_SGIS_multisample GLX_SGIX_fbconfig GLX_SGIX_pbuffer GLX_SGIX_visual_select_group GLX_INTEL_swap_event
Window manager	GNOME Shell
XDG_CURRENT_DESKTOP	GNOME
GDMSESSION	gnome-xorg
Compositing manager	Yes
Direct rendering	Yes
Reset notification strategy	0x8252
GPU process crash count	0
System visual ID	71
RGBA visual ID	442
Compositor Information
Tile Update Mode	Zero-copy
Partial Raster	Enabled
GpuMemoryBuffers Status
R_8	Software only
R_16	Software only
RG_88	Software only
BGR_565	Software only
RGBA_4444	Software only
RGBX_8888	Software only
RGBA_8888	Software only
BGRX_8888	Software only
BGRX_1010102	Software only
RGBX_1010102	Software only
BGRA_8888	Software only
RGBA_F16	Software only
YVU_420	Software only
YUV_420_BIPLANAR	Software only
UYVY_422	Software only
Display(s) Information
Info	Display[21691165392765032] bounds=[0,0 1920x1080], workarea=[0,27 1920x1053], scale=2, external.
Color space information	{primaries:INVALID, transfer:INVALID, matrix:INVALID, range:INVALID}
Bits per color component	8
Bits per pixel	24
Video Acceleration Information
Decode h264 baseline	up to 4096x4096 pixels
Decode h264 main	up to 4096x4096 pixels
Decode h264 high	up to 4096x4096 pixels
Decode vp8	up to 4096x4096 pixels
Decode vp9 profile0	up to 4096x4096 pixels
Decode vp9 profile2	up to 4096x4096 pixels
Encode h264 baseline	up to 4096x4096 pixels and/or 30.000 fps
Encode h264 main	up to 4096x4096 pixels and/or 30.000 fps
Encode h264 high	up to 4096x4096 pixels and/or 30.000 fps
Encode vp8	up to 4096x4096 pixels and/or 30.000 fps
Encode vp9 profile0	up to 4096x4096 pixels and/or 30.000 fps
Log Messages
[2026:2026:0313/132010.916776:ERROR:sandbox_linux.cc(364)] : InitializeSandbox() called with multiple threads in process gpu-process.
[2026:2026:0313/132036.363268:ERROR:buffer_manager.cc(488)] : [.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error from previous GL command
[2026:2026:0313/132059.170534:ERROR:buffer_manager.cc(488)] : [.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error from previous GL command
[2026:2026:0313/132101.023385:ERROR:buffer_manager.cc(488)] : [.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error from previous GL command

render_id: 24
player_id: 37
origin_url: https://www.youtube.com/
frame_url: https://www.youtube.com/watch?v=F_Hfa1GJ_q4
frame_title: (63) YouTube
surface_layer_mode: kOnDemand
url: blob:https://www.youtube.com/39383ea2-dd7c-4495-a7b7-5b7368e26930
info: Selected MojoVideoDecoder for video decoding, config: codec: vp9, format: PIXEL_FORMAT_I420, profile: vp9 profile0, coded size: [656,480], visible rect: [0,0,656,480], natural size: [656,480], has extra data: false, encryption scheme: Unencrypted, rotation: 0°
pipeline_state: kPlaying
found_audio_stream: true
audio_codec_name: opus
found_video_stream: true
video_codec_name: vp9
audio_dds: false
audio_decoder: FFmpegAudioDecoder
is_platform_audio_decoder: false
video_dds: false
video_decoder: MojoVideoDecoder
is_platform_video_decoder: true
audio_buffering_state: BUFFERING_HAVE_ENOUGH
duration: 1747.741
seek_target: 222.264391

digitalone · 2019-03-13 19:30:39

Version 73 works good to me. Could be a driver issue, no problem with radeon.

seth · 2019-03-13 20:25:08

Tried to drop xf86-video-intel (to use the modesetting driver)?

maximbaz · 2019-03-13 21:02:23

I confirm that VP9 videos on Intel don't play since v73, foutrelis and I are looking into it

digitalone · 2019-03-13 22:06:59

Vp9 on my system are not hardware decoded, I use h264ify. Did you try to decode h264 content?

sjk132 · 2019-03-14 02:14:02

h264 works

render_id: 30
player_id: 31
origin_url: https://www.youtube.com/
frame_url: https://www.youtube.com/watch?v=oSMww0UG3OY
frame_title: YouTube
surface_layer_mode: kOnDemand
url: blob:https://www.youtube.com/cda4f246-e009-4b08-854d-98503949b70c
info: Selected video track: [2]
pipeline_state: kSuspended
found_audio_stream: true
audio_codec_name: aac
found_video_stream: true
video_codec_name: h264
debug: (Log limit reached. Further similar entries may be suppressed): ISO-BMFF container metadata for video frame indicates that the frame is a keyframe, but the video frame contents indicate the opposite.
audio_dds: false
audio_decoder: FFmpegAudioDecoder
is_platform_audio_decoder: false
video_dds: false
video_decoder: MojoVideoDecoder
is_platform_video_decoder: true
audio_buffering_state: BUFFERING_HAVE_ENOUGH
height: 720
width: 960
video_buffering_state: BUFFERING_HAVE_ENOUGH
for_suspended_start: false
pipeline_buffering_state: BUFFERING_HAVE_ENOUGH
event: SUSPENDED
duration: 62.13662

miomio · 2019-03-14 02:32:46

Upgrading to 73 broke YouTube videos for me (using h264ify extension switching from VP9 format) in that if I skip the video from the progress bar the video fails. If I turn off h264ify and let YT render with VP9 via software decode, I don't have issue.

Basically, upgrading to 73 made this an issue for me: https://github.com/intel/media-driver/i … -462171762

It wasn't a problem with 72.

(EDIT: SKL CPU. Doesn't support hw VP9)

Last edited by miomio (2019-03-14 02:51:18)

sjk132 · 2019-03-14 04:44:24

miomio wrote:

Upgrading to 73 broke YouTube videos for me (using h264ify extension switching from VP9 format) in that if I skip the video from the progress bar the video fails. If I turn off h264ify and let YT render with VP9 via software decode, I don't have issue.
Basically, upgrading to 73 made this an issue for me: https://github.com/intel/media-driver/i … -462171762
It wasn't a problem with 72.
(EDIT: SKL CPU. Doesn't support hw VP9)

try libva-intel-driver

maximbaz · 2019-03-14 14:14:36

We were unable to identify the root cause for the issue, tried commenting back the use of system libvpx, didn't help. If someone has any ideas, or a patch for PKGBUILD that would fix VP9 video decoding, please share.

Until then, yes using h264ify extension is the best available workaround.

Batou · 2019-03-15 05:23:04

I updated Chromium today and it stutters like mad now. Previous version I had was near-perfect. I use Chromium for my job, web dev, and FF for daily browsing. This latest update completely broke Chromium for me. :\

foutrelis · 2019-03-15 21:49:25

The VP9 playback issue was severe enough to warrant going back to non-VAAPI Chromium (starting with 73.0.3683.75-2). Along with seeking issues with the iHD driver and system hangs with AMDGPU, I seem to have overestimated how well it would work on most GPUs. Hopefully, Maxim will be able to keep it alive as chromium-vaapi.

digitalone · 2019-03-15 22:14:02

I hope chromium-vaapi will be available on the AUR, I don't need vp9 and never had issues with h264 decoding.

maximbaz · 2019-03-15 22:51:47

I'll revive chromium-vaapi package, it's compiling now, I'll update afterwards. If you want pre-compiled package, use chromium-vaapi-bin or add my repo to your pacman config.

nitrobay · 2019-04-04 16:32:00

.

Last edited by nitrobay (2019-04-09 20:09:34)

colemickens · 2019-04-14 20:41:33

maximbaz, I have been trying to package these changes for NixOS/nixpkgs. I got the change in and then quickly discovered similar issues as have been found here in Arch (radeon, vp9 issues, at least).

I am curious, have you been in contact with any of the authors of these patches originally, or any of the maintainers from Fedora?

I'm interested in seeing if vaapi can be enabled in the build, but disabled at runtime, and then enabled at runtime either via a flag. However, when I took a look, this would take more than just a trivial change to the current patch(es).

I figure we might as well corral efforts if there are a number of distros interested in getting this enabled? I'm `colemickens` on IRC too, if you want to ping me there.

maximbaz · 2019-04-14 21:39:30

Hey, it would be awesome if you package vaapi for NixOS/nixpkgs!

No I haven't been in contact with patch authors or Fedora maintainers, but I'm not very experienced or involved in this area to be honest, some folks here are way more experienced than me, let's see, maybe someone was in contact and will reply in this thread.

It actually used to be like you want in earlier patches, where in addition to compiling with vaapi you also had to provide a couple of flags in order to actually activate vaapi, but then patches changed and the new ones come with vaapi enabled without any flags.

Not sure if foutrelis would consider re-adding the patch to official Chromium if activating it required providing extra flag(s), but if we stay with chromium-vaapi on AUR, I think we will just continue with the current patch that enables vaapi by default.

sparsa · 2019-04-17 04:35:46

I have installed both intel-media-driver and also libva-intel-driver but vainfo takes i965 as default always how to set LIBVA_DRIVER_NAME permanently to iHD

svito · 2019-04-17 04:42:26

sparsa wrote:

I have installed both intel-media-driver and also libva-intel-driver but vainfo takes i965 as default always how to set LIBVA_DRIVER_NAME permanently to iHD

See the first post, it links to the wiki where everything is explained, including how to set environment variables.

xuanrui · 2019-05-01 05:35:44

A question about building chromium-vaapi: it seems that I can't distribute the build using DistCC. Is anyone successful? I get the following error message:

(dcc_build_somewhere) Warning: failed to distribute, running locally instead

This is not a problem with my DistCC setup. I can use DistCC to build other packages just fine. It's not a problem with DistCC whitelisting either: I have added clang and clang++ to the distcc whitelist.

realh · 2019-05-10 20:07:39

Gusar wrote:

Another point, in order to have hardware decoded video be part of a webpage, a browser first needs hardware accelerated webpage rendering. Firefox simply does not have that on Linux, not in a working state at least. Mozilla has been developing a new renderer for some now, called Webrender. Unlike their current renderer (which only works well in D3D mode, so on Windows), Webrender one is designed to also work on Linux. It needs to be finished first before Mozilla can begin tackling hardware video decoding.

However, they have WebGL working with acceleration without Webrender, don't they? VAAPI can output directly to an OpenGL surface, so I would have thought they'd be able to use whatever method they use to embed an accelerated canvas to provide accelerated video too. But perhaps there's some important difference between the two types of element that's getting in the way?

Gusar · 2019-05-10 21:07:02

realh wrote:

But perhaps there's some important difference between the two types of element that's getting in the way?

I vaguely recall that WebGL came up once and it was explained that there indeed is a difference. But I don't remember where I read it, whether it was on Mozilla's Bugzilla or reddit, or somewhere else.

Edit: A quick search found this: https://old.reddit.com/r/firefox/commen … i/ekdnc4p/ <- apparently Firefox does readback for WebGL on Linux, so performance is terrible. Doing readback for video negates a lot of the advantage of using hardware decoding, it's not worth the bother.

Last edited by Gusar (2019-05-10 21:14:17)

realh · 2019-05-11 15:10:32

Gusar wrote:

[Edit: A quick search found this: https://old.reddit.com/r/firefox/commen … i/ekdnc4p/ <- apparently Firefox does readback for WebGL on Linux, so performance is terrible. Doing readback for video negates a lot of the advantage of using hardware decoding, it's not worth the bother.

I see, so it's more that they had the same problem with both than that there's an important difference. But CPU-only 3D rendering is more likely to result in dire performance than video decoding, so an unsatisfactory solution was worth keeping for now. Whereas their earlier attempt at video was based on gstreamer 0.x, which was pretty flaky with vaapi, so they were better off reverting to ffmpeg. I hope Mozilla haven't been put off gstreamer altogether, because post-1.x it's vastly improved and could save them from reinventing the wheel and having to deal with a number of different APIs. If they could support NVDEC (unlikely, and a certain Linux quote springs to mind) as well as VAAPI, while Google continue not to officially support either, FF would be hands down the browser of choice for Linux. It's understandable that Mozilla don't want to fix the current code if it's going to be replaced with Webrender, but I hope they've been considering GPU video acceleration on Linux as a high priority all the while developing that.

Last edited by realh (2019-05-11 15:11:43)

Gusar · 2019-05-12 20:03:49

realh wrote:

Whereas their earlier attempt at video was based on gstreamer 0.x, which was pretty flaky with vaapi, so they were better off reverting to ffmpeg.

Not just with vaapi, there were other issues with gstreamer too, that's why they dropped it.

realh wrote:

I hope Mozilla haven't been put off gstreamer altogether, because post-1.x it's vastly improved and could save them from reinventing the wheel and having to deal with a number of different APIs.

While gstreamer may have improved over the years, I don't see Mozilla switching back. They don't need to, they get all they need from using ffmpeg directly. It has interfaces to all the hardware decode APIs, so there's no more reinventing the wheel than there would be with gstreamer.

realh wrote:

I hope they've been considering GPU video acceleration on Linux as a high priority all the while developing that.

Nothing about Linux is high priority at Mozilla, so I wouldn't get my hopes up.

realh · 2019-05-13 11:34:01

Gusar wrote:

[While gstreamer may have improved over the years, I don't see Mozilla switching back. They don't need to, they get all they need from using ffmpeg directly. It has interfaces to all the hardware decode APIs, so there's no more reinventing the wheel than there would be with gstreamer.

I posted something similar on Bugzilla, and got a response saying it isn't as simple as that. That's probably true, otherwise why would Chromium have a "MojoVideoDecoder" in addition to the ffmpeg one? Presumably ffmpeg still leaves you with a lot of work to do like getting encoded frames from an ffmpeg demuxer then feeding them yourself to the decoder and then to the display, whereas gstreamer takes care of every step for you.

I tried out GNOME Web (Epiphany) last night, because that supports vaapi via gstreamer, and it works reasonably well for youtube, but I don't think it could replace Chrome/Chromium as my everyday browser yet. It's a bit easier for Firefox users to make the switch, because Web can sync with your FF account.

afader · 2019-06-16 04:25:35

This was working for me in nvidia until recently with h264ify. Maybe we can use system ffmpeg which can be compiled with NVDEC.

Arch Linux

#51 2019-03-13 18:23:43

Re: chromium: hardware video acceleration with VA-API

#52 2019-03-13 19:30:39

Re: chromium: hardware video acceleration with VA-API

#53 2019-03-13 20:25:08

Re: chromium: hardware video acceleration with VA-API

#54 2019-03-13 21:02:23

Re: chromium: hardware video acceleration with VA-API

#55 2019-03-13 22:06:59

Re: chromium: hardware video acceleration with VA-API

#56 2019-03-14 02:14:02

Re: chromium: hardware video acceleration with VA-API

#57 2019-03-14 02:32:46

Re: chromium: hardware video acceleration with VA-API

#58 2019-03-14 04:44:24

Re: chromium: hardware video acceleration with VA-API

#59 2019-03-14 14:14:36

Re: chromium: hardware video acceleration with VA-API

#60 2019-03-15 05:23:04

Re: chromium: hardware video acceleration with VA-API

#61 2019-03-15 21:49:25

Re: chromium: hardware video acceleration with VA-API

#62 2019-03-15 22:14:02

Re: chromium: hardware video acceleration with VA-API

#63 2019-03-15 22:51:47

Re: chromium: hardware video acceleration with VA-API

#64 2019-04-04 16:32:00

Re: chromium: hardware video acceleration with VA-API

#65 2019-04-14 20:41:33

Re: chromium: hardware video acceleration with VA-API

#66 2019-04-14 21:39:30

Re: chromium: hardware video acceleration with VA-API

#67 2019-04-17 04:35:46

Re: chromium: hardware video acceleration with VA-API

#68 2019-04-17 04:42:26

Re: chromium: hardware video acceleration with VA-API

#69 2019-05-01 05:35:44

Re: chromium: hardware video acceleration with VA-API

#70 2019-05-10 20:07:39

Re: chromium: hardware video acceleration with VA-API

#71 2019-05-10 21:07:02

Re: chromium: hardware video acceleration with VA-API

#72 2019-05-11 15:10:32

Re: chromium: hardware video acceleration with VA-API

#73 2019-05-12 20:03:49

Re: chromium: hardware video acceleration with VA-API

#74 2019-05-13 11:34:01

Re: chromium: hardware video acceleration with VA-API

#75 2019-06-16 04:25:35

Re: chromium: hardware video acceleration with VA-API

Board footer