chromium: hardware video acceleration with VA-API

justkdng · 2019-12-14 01:57:12

liewkj wrote:

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.

I guess that only works for xwayland and not ozone right?

liewkj · 2019-12-14 02:31:18

justkdng wrote:

I guess that only works for xwayland and not ozone right?

I knew nothing about ozone and haven't looked into that. AFAIK, ozone is another platform abstraction layer to simplify Chrome/ChromeOS porting and deployment. But it is still largely WIP, perhaps with exception for ChromeOS itself. And for platform abstraction, it will definitely abstract the display contexts management out from the upper layers. So stuffs that deal with platform specific implementations (display, GL, video encode/decode etc.) would all be within ozone and Chrome simply calls high-level APIs from ozone which are ideally consistent across all platforms. Such is a Utopian concept in software designs but it may have performance impact of introducing another middle-layer between software and hardware.

liewkj · 2019-12-14 03:23:34

It seems that the maintainer of iHD VA driver does not want to have display support in Intel media-driver
https://github.com/intel/media-driver/i … -562400193

So that leaves chromium-vaapi with the only option of getting VA-API over DRM, and apparently Chromium already supported that, if not for the bug and the XWayland vsync issue introduced in xorg-server 1.20. Downgrading xorg-server to 1.19 is another option which I didn't not verify. Integrating the 4 commits into xorg-server 1.20.6 release seems to have other issues, glxgears and es2gears_x11 have black window if 1st run after reboot but work fine after Ctrl-C and rerun. Only need one of them to run once or after any GL applications, then both will be fine thereafter.

maximbaz · 2019-12-14 14:25:30

Thank you, very interesting. I don't use Wayland, but I compiled chromium with your patch if someone wants to try - please share your feedback here
https://pkgbuild.com/~maximbaz/repo/chr … pkg.tar.xz

afader · 2019-12-15 05:34:57

Chromium-vaapi 79 from maximbaz' repo is giving me Ffmpeg instead of Mojo video decoder on Nvidia. Using kernel 5.4.3 and latest nvidia-beta drivers.

Also I noticed in 79 there is an option to enable Vulkan but it simply crashes for me. I haven't tried it on vanilla chromium.

Last edited by afader (2019-12-15 05:42:54)

liewkj · 2019-12-15 09:45:08

afader wrote:

Chromium-vaapi 79 from maximbaz' repo is giving me Ffmpeg instead of Mojo video decoder on Nvidia. Using kernel 5.4.3 and latest nvidia-beta drivers.

Unfortunately, I confirmed your plight with nvidia-390xx. So look like the wrapper has finally given up, too bad. That isn't anything much we can do now, if switching to the open-sourced, half-baked nouveau driver is not an option for you.

[1165:1165:1215/012352.755274:ERROR:vaapi_wrapper.cc(2149)] vaCreateSurfaces failed VA error: attribute not supported
[1516:19:1215/012352.755622:ERROR:batching_media_log.cc(26)] MediaEvent: MEDIA_ERROR_LOG_ENTRY {"error":"VDA Error 4"}

afader wrote:

Also I noticed in 79 there is an option to enable Vulkan but it simply crashes for me. I haven't tried it on vanilla chromium.

Vulkan does not provide acceleration for video decoding, but acceleration for rendering. Such has always been available from all the software decoders with OpenGL.

maximbaz · 2019-12-15 11:36:36

@afader: does -3 specifically break our video encoding, or -2 as well? As far as I understood, the vaapi-wayland.patch in -3 should not break anything?

maximbaz · 2019-12-15 12:32:22

Someone on AUR mentioned this as well, and they say this patch fixes the issue: https://github.com/saiarcot895/chromium … 3R379-R410

Do you guys think this patch makes sense? I can build a Chromium for you if you like to test.

Relevant thread: https://github.com/saiarcot895/chromium … /issues/58

Last edited by maximbaz (2019-12-15 12:33:04)

akarshanbiswas · 2019-12-15 17:56:23

Has anyone tried vaapi using the Vulkan api backend in chromium 79?

BTW, chromium with vulkan is super fast!!!!

liewkj · 2019-12-15 18:16:12

maximbaz wrote:

Someone on AUR mentioned this as well, and they say this patch fixes the issue: https://github.com/saiarcot895/chromium … 3R379-R410
Do you guys think this patch makes sense? I can build a Chromium for you if you like to test.
Relevant thread: https://github.com/saiarcot895/chromium … /issues/58

No, I would not recommend such an ugly patch in Chromium. I have a working one which patch VDPAU wrapper for VA-API, which is clean from patching Chromium. But we need to slightly modify the Wayland fix as it is crashing GPU process from time-to-time, so we can either skip that for VDPAU wapper or only do it for Intel drivers. I am leaning towards the later because MESA VA drivers already have DRI3 support and they do not need the vaGetDisplayDRM() code path for XWayland.

Last edited by liewkj (2019-12-15 18:29:50)

afader · 2019-12-15 20:07:58

It seems to be broken in all of Chromium 79 builds, -2 and -3 alike. I reverted to 78 for now and it works fine. I would love to try to the Vulkan backend for rendering but it doesn't work, any suggestions how to enable it? Do I need to pass use-gl=vulkan? I'm using Xorg, not Wayland, in GNOME with the proprietary binary nvidia driver and I'd rather not go to nouveau. I also have libva-vdpau-driver-chromium installed. Here is my chromium-flags and I also go through and turn on most of the hardware accel/viz related flags in chromium flags. I show green and turned on for everything in chromium://gpu and I show MojoVideoDecoder when using 78.

I would love to test any patches that are available

--disable-features=HardwareMediaKeyHandling,OmniboxUIExperimentHideSteadyStateUrlPathQueryAndRef,OmniboxUIExperimentHideSteadyStateUrlScheme,OmniboxUIExperimentHideSteadyStateUrlTrivialSubdomains,ShowManagedUi
--disable-font-subpixel-positioning 
--disable-gpu-driver-bug-workarounds
--disable-gpu-driver-workarounds
--enable-accelerated-2d-canvas
--enable-accelerated-mjpeg-decode
--enable-accelerated-video
--enable-features=MarkHttpAs,StrictOriginIsolation
--enable-gpu-memory-buffer-compositor-resources
--enable-gpu-memory-buffer-video-frames
--enable-gpu-rasterization
--enable-native-gpu-memory-buffers
--enable-quic
--enable-smooth-scrolling
--enable-tcp-fastopen
--enable-zero-copy
--force-gpu-rasterization
--high-dpi-support=1
--ignore-gpu-blacklist
--enable-features=CheckerImaging

I added the vaapi-fix per the AUR post and I eventually hit a compilation error with libprotobuf - I have the latest one installed and it has been breaking various things on my system. I can build in a clean chroot or downgrade and try again, although i assume this will have to be fixed upstream eventually.

ImportError: No module named protobuf.descriptor_pb2
--plugin_out: protoc-gen-plugin: Plugin failed with status code 1.
Protoc has returned non-zero status: 1
[11659/37009] ACTION //third_party/dom_distiller_js:json_values_converter_test_proto_gen(//build/toolchain/linux/unbundle:default)
FAILED: pyproto/third_party/dom_distiller_js/test_sample_pb2.py gen/third_party/dom_distiller_js/test_sample.pb.h gen/third_party/dom_distiller_js/test_sample.pb.cc gen/third_party/dom_distiller_js/test_sample_json_converter.h 
/usr/bin/python2 ../../tools/protoc_wrapper/protoc_wrapper.py test_sample.proto --protoc ./protoc --proto-in-dir ../../third_party/dom_distiller_js --cc-out-dir gen/third_party/dom_distiller_js --py-out-dir pyproto/third_party/dom_distiller_js --plugin ../../third_party/dom_distiller_js/protoc_plugins/json_values_converter.py --plugin-out-dir gen/third_party/dom_distiller_js --plugin-options output_dir=:
Traceback (most recent call last):
  File "../../third_party/dom_distiller_js/protoc_plugins/json_values_converter.py", line 14, in <module>
    from util import plugin_protos, types, writer
  File "/mnt/external/chromium-vaapi/src/chromium-79.0.3945.79/third_party/dom_distiller_js/protoc_plugins/util/plugin_protos.py", line 22, in <module>
    from google.protobuf.descriptor_pb2 import FieldDescriptorProto
ImportError: No module named protobuf.descriptor_pb2
--plugin_out: protoc-gen-plugin: Plugin failed with status code 1.
Protoc has returned non-zero status: 1
[11667/37009] CXX obj/media/remoting/media_remoting_proto/media_remoting_rpc.pb.o

Last edited by afader (2019-12-15 22:01:48)

liewkj · 2019-12-15 22:02:51

Here's the patch for libva-vdpau-driver-chromium. It keeps Chromium clean from ugly patch that simply revert everything Google has done for Chromium-79 with out-of-mind #ifdef/#endif. Probably one could just simply never upgrade from Chromium-78.

diff -Nru src/libva-vdpau-driver-0.7.4/src/vdpau_driver_template.h new/libva-vdpau-driver-0.7.4/src/vdpau_driver_template.h
--- src/libva-vdpau-driver-0.7.4/src/vdpau_driver_template.h    2019-12-15 03:05:41.353188084 -0800
+++ new/libva-vdpau-driver-0.7.4/src/vdpau_driver_template.h    2019-12-15 02:58:10.729756522 -0800
@@ -452,6 +452,19 @@
                 void **buffer
         );
 #endif
+
+        VAStatus
+        (*vaCreateSurfaces2)(
+            VADriverContextP    ctx,
+            unsigned int        format,
+            unsigned int        width,
+            unsigned int        height,
+            VASurfaceID        *surfaces,
+            unsigned int        num_surfaces,
+            VASurfaceAttrib    *attrib_list,
+            unsigned int        num_attribs
+        );
+
 };

 /* Driver context */
@@ -662,6 +675,7 @@
     vtable->vaDbgCopySurfaceToBuffer        = vdpau_DbgCopySurfaceToBuffer;
 #endif
 #endif
+    vtable->vaCreateSurfaces2               = vdpau_CreateSurfaces2;

 #if VA_INIT_GLX
     VA_DRIVER_VTABLE_GLX_P const glx_vtable = FUNC(GetVTableGLX)(ctx);
diff -Nru src/libva-vdpau-driver-0.7.4/src/vdpau_video.c new/libva-vdpau-driver-0.7.4/src/vdpau_video.c
--- src/libva-vdpau-driver-0.7.4/src/vdpau_video.c      2019-12-15 03:05:41.363188087 -0800
+++ new/libva-vdpau-driver-0.7.4/src/vdpau_video.c      2019-12-15 02:57:34.663083228 -0800
@@ -501,6 +504,22 @@
     return va_status;
 }

+// vaCreateSurfaces2
+VAStatus
+vdpau_CreateSurfaces2(
+    VADriverContextP    ctx,
+    unsigned int        format,
+    unsigned int        width,
+    unsigned int        height,
+    VASurfaceID         *surfaces,
+    unsigned int        num_surfaces,
+    VASurfaceAttrib     *attrib_list,
+    unsigned int        num_attribs
+)
+{
+    return vdpau_CreateSurfaces(ctx, width, height, format, num_surfaces, surfaces); 
+}
+
 // vaDestroyContext
 VAStatus vdpau_DestroyContext(VADriverContextP ctx, VAContextID context)
 {
diff -Nru src/libva-vdpau-driver-0.7.4/src/vdpau_video.h new/libva-vdpau-driver-0.7.4/src/vdpau_video.h
--- src/libva-vdpau-driver-0.7.4/src/vdpau_video.h      2019-12-15 03:05:41.363188087 -0800
+++ new/libva-vdpau-driver-0.7.4/src/vdpau_video.h      2019-12-15 02:57:32.999749599 -0800
@@ -185,6 +185,19 @@
     VASurfaceID        *surfaces
 ) attribute_hidden;

+// vaCreateSurfaces2
+VAStatus
+vdpau_CreateSurfaces2(
+    VADriverContextP    ctx,
+    unsigned int        format,
+    unsigned int        width,
+    unsigned int        height,
+    VASurfaceID        *surfaces,
+    unsigned int        num_surfaces,
+    VASurfaceAttrib    *attrib_list,
+    unsigned int        num_attribs
+) attribute_hidden;
+
 // vaDestroySurfaces
 VAStatus
 vdpau_DestroySurfaces(

Unfortunately, we also need to revert the Wayland fix for Intel i965 VA driver. We are now stuck with circular dependency between UI/GL and VA-API initialization. VA vendor string is not available before VA-API initialization and VA-API initialization requires UI/GL initialization to be able to select vaGetDisplayDRM() path for Intel i965 VA driver. So pick your camp, favor Intel i965 VA driver for Wayland endorsement (once XWayland V-Sync is fixed) or NVIDIA arrogance towards open-source and the crappy VDPAU wrapper solution.

Long-term solution would be to understand why gl::init::InitializeGLOneOff() faulted if it is Chromium or NVIDIA to blame, but this will take some time and Google would care less about NVIDIA especially with the propriety blobs.

Actually, we can also add new gl::init method to initialize GL implementation without really going through the entire UI/GL initialization. Then we can use the new method before VA-API initialization. I can take a look for this patch for Chromium.

Last edited by liewkj (2019-12-15 22:08:27)

kkkkkking · 2019-12-16 16:13:57

Don't see anyone reporting, but -3 works on my Skylake machine, reporting Mojo video decoder with some lag and vsync error. Both i965 and iHD show the same result.

Also I have trouble with #enable-vulkan on both X11 and Wayland, getting GPU crashing error and no idea how to do any logging or debugging.

afader · 2019-12-16 16:20:25

I have patched libva-vdpau-driver-chromium with the latest patch from @liewkj and everything seems to be happy now for Mojo on youtube videos on chromium-vaapi 79.0.3945.79-4 from maximbaz. Thank you!

maximbaz · 2019-12-16 17:05:06

akarshanbiswas wrote:

Has anyone tried vaapi using the Vulkan api backend in chromium 79?
BTW, chromium with vulkan is super fast!!!!

If I launch chromium with --use-vulkan, chrome://gpu goes from everything green to everything yellow or red, and youtube falls back to VpxVideoDecoder.

justkdng · 2019-12-16 17:14:54

@maximbaz

I think that is because vulkan support is behind a gn flag: enable_vulkan
Even if I pass --use-vulkan in chrome://gpu it says vulkan is disabled

liewkj · 2019-12-17 03:32:09

Here's the patch to restore Intel i965 VA driver for Wayland without explicit call to gl::init::InitializeGLOneOff().

diff -ru orig/chromium-79.0.3945.79/ui/gl/gl_implementation.cc ./src/chromium-79.0.3945.79/ui/gl/gl_implementation.cc
--- orig/chromium-79.0.3945.79/ui/gl/gl_implementation.cc       2019-12-09 13:51:59.000000000 -0800
+++ ./src/chromium-79.0.3945.79/ui/gl/gl_implementation.cc      2019-12-15 20:31:41.636391442 -0800
@@ -141,6 +141,15 @@
   return g_gl_implementation;
 }

+GLImplementation GetGLImplHintFromCmdLine() {
+  const base::CommandLine* cmd = base::CommandLine::ForCurrentProcess();
+  std::string requested_implementation_name =
+      cmd->GetSwitchValueASCII(switches::kUseGL);
+  if (kGLImplementationNone == GetGLImplementation())
+    return GetNamedGLImplementation(requested_implementation_name);
+  return GetGLImplementation();
+}
+
 bool HasDesktopGLFeatures() {
   return kGLImplementationDesktopGL == g_gl_implementation ||
          kGLImplementationDesktopGLCoreProfile == g_gl_implementation ||
diff -ru orig/chromium-79.0.3945.79/ui/gl/gl_implementation.h ./src/chromium-79.0.3945.79/ui/gl/gl_implementation.h
--- orig/chromium-79.0.3945.79/ui/gl/gl_implementation.h        2019-12-09 13:51:34.000000000 -0800
+++ ./src/chromium-79.0.3945.79/ui/gl/gl_implementation.h       2019-12-15 20:24:10.338854631 -0800
@@ -85,6 +85,9 @@
 // Get the current GL implementation.
 GL_EXPORT GLImplementation GetGLImplementation();

+// Get the current GL implementation hint from --use-gl
+GL_EXPORT GLImplementation GetGLImplHintFromCmdLine();
+
 // Get the software GL implementation for the current platform.
 GL_EXPORT GLImplementation GetSoftwareGLImplementation();

diff -ru orig/chromium-79.0.3945.79/media/gpu/vaapi/vaapi_wrapper.cc ./src/chromium-79.0.3945.79/media/gpu/vaapi/vaapi_wrapper.cc
--- 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-16 11:46:55.677408397 -0800
@@ -371,7 +374,7 @@
       VA_MAJOR_VERSION >= 2 || (VA_MAJOR_VERSION == 1 && VA_MINOR_VERSION >= 1),
       "Requires VA-API >= 1.1.0");

-  switch (gl::GetGLImplementation()) {
+  switch (gl::GetGLImplHintFromCmdLine()) {
     case gl::kGLImplementationEGLGLES2:
       va_display_ = vaGetDisplayDRM(drm_fd_.get());
       break;
@@ -395,7 +398,7 @@

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

However, from a personal taste of patch ethics, this is less than ideal because it creates a diversion from original code intent of relying on true GL implementation to hint from "--use-gl" switch. Chromium has sandbox infrastructure for GPU process and an unlikely restart of GPU process with different GL implementation from the switch would be troublesome. A more elegant fix would be to enforce proper serialization to ensure GL implementation is valid during VA-API initialization. However, looking at the code that it indeed handles case for kGLImplementationNone, serialization may not be the design intent perhaps for the browser's boot performance. If indeed serialization was required, then the fix would most probably come from Google engineers as this requires in-depth knowledge of Chromium IPC mechanism.

So then we come to the 2nd next possible solution. The kGLImplementationNone code path relies on vaDisplayIsValid() to be able to iterate all possible displays is a flawed assumption. Neither libva nor VA drivers make use of vaDisplayIsValid() to qualify the underlying DRI2/DRI3/DRM infrastructures. Intel i965 VA driver does this during vaInitialize(). The correct kGLImplementationNone case for iterating all possible displays should in fact include vaInitialize(). This is the place where a patch is also possible for Chromium. Alternatively, one can also fix VA drivers to tighten up the sanity check for vaDisplayIsValid().

Anyway, the 1st Chromium patch posted for archiving purposes and when XWayland finally resolved its v-sync issues, hardware accelerated video decoding would no longer be an issue for Wayland endorsement.

xtknight · 2019-12-22 15:54:07

For those interested, I have started an experimental project that modifies vdpau-va-driver (VAAPI wrapper) to include support for VP9 on NVIDIA GPUs. It seems to work for the videos I've tried so far and would appreciate more testers. Although I've tested only on Ubuntu 19.10, I don't think there should be any barriers for this working on ArchLinux.

https://github.com/xtknight/vdpau-va-driver-vp9

afader · 2019-12-23 00:19:42

My nvidia-settings doesn't think I can decode VP9 with VDPAU. I have a GTX 970. Would your patch give me NVDEC support?

Also, I have a problem now where I can't make my youtube videos full-screen.

xtknight · 2019-12-23 03:53:28

afader wrote:

My nvidia-settings doesn't think I can decode VP9 with VDPAU. I have a GTX 970. Would your patch give me NVDEC support?
Also, I have a problem now where I can't make my youtube videos full-screen.

Unfortunately, it seems like the GTX 970 doesn't support VP9 decode in VDPAU. My patch only allows support if the underlying NVIDIA driver and card support it. However, you can watch h.264 videos with hardware acceleration with the existing VDPAU-VAAPI wrapper. About fullscreen, I haven't modified anything related to fullscreening in this patch but that may be an issue unrelated to VDPAU.

https://developer.nvidia.com/video-enco … ort-matrix

Last edited by xtknight (2019-12-23 03:56:27)

akarshanbiswas · 2019-12-23 14:41:23

maximbaz wrote:

akarshanbiswas wrote:
Has anyone tried vaapi using the Vulkan api backend in chromium 79?
BTW, chromium with vulkan is super fast!!!!
If I launch chromium with --use-vulkan, chrome://gpu goes from everything green to everything yellow or red, and youtube falls back to VpxVideoDecoder.

Unfortunately Radeon mesa drivers doesn't support VulkanVaapiDisplay, so getting a white frame with normal audio.

afader · 2019-12-25 03:26:31

The fullscreen issue is probably something that could be fixed in @liewkj patch. I'm not sure when it started but must have been recently. Patch works well otherwise.

My workaround is to use play-with-mpv which always uses cuda/nvdec. Shame we can't implement that as a plugin to chromium. Edit: Turns out you can do this with mozplugger and viewtube. So far so good...

Edit 2: So the viewtube thing doesn't use mozplugger on chromium, but I definitely get better video quality using it. It still shows Mojo through vaapi. Also, the fullscreen thing is fixed by using system title bar and borders so disregard that.

Last edited by afader (2019-12-25 05:05:12)

mbrennr · 2020-01-10 07:03:46

afader wrote:

I have patched libva-vdpau-driver-chromium with the latest patch from @liewkj and everything seems to be happy now for Mojo on youtube videos on chromium-vaapi 79.0.3945.79-4 from maximbaz. Thank you!

Nice!
I can't get this to work, and the AUR libva-vdpau-driver-chromium 0.7.4-6 didn't include this.
Please, can you describe how you did it? Thanks in advance.

sl1pkn07 gone MIA?

liewkj · 2020-01-10 09:22:46

Don't you know how to apply a patch, do you?
This is a very simple instruction, and I hope that you are able to follow.
It assumes that you will be building the AUR package in ${HOME}/AUR.
Save the patch as plain text as ${HOME}/mypatch.txt.

$ cd ~/AUR
$ wget https://aur.archlinux.org/cgit/aur.git/snapshot/libva-vdpau-driver-chromium.tar.gz
$ tar xf libva-vdpau-driver-chromium.tar.gz
$ cd libva-vdpau-driver-chromium
$ makepkg -sfo
$ cd src
$ patch -Np1 -i ~/mypatch.txt
$ cd ..
$ makepkg -ei

Good luck!

mbrennr · 2020-01-10 10:04:42

liewkj wrote:

Don't you know how to apply a patch, do you?
This is a very simple instruction, and I hope that you are able to follow.
It assumes that you will be building the AUR package in ${HOME}/AUR.
Save the patch as plain text as ${HOME}/mypatch.txt.
$ cd ~/AUR
$ wget https://aur.archlinux.org/cgit/aur.git/snapshot/libva-vdpau-driver-chromium.tar.gz
$ tar xf libva-vdpau-driver-chromium.tar.gz
$ cd libva-vdpau-driver-chromium
$ makepkg -sfo
$ cd src
$ patch -Np1 -i ~/mypatch.txt
$ cd ..
$ makepkg -ei
Good luck!

Ok, thank you! I'll try it with manual patching and mkpkg -sfo.
Forgot to specify my method, I tried to apply this with PKGBUILD modifications in my ~/.cache/yay... with just makepkg -f.
There are more patches in the PKGBUILD prepare(), maybe something in the other patches messed things up.
I guess that's why it's not in the AUR yet.

Arch Linux

#251 2019-12-14 01:57:12

Re: chromium: hardware video acceleration with VA-API

#252 2019-12-14 02:31:18

Re: chromium: hardware video acceleration with VA-API

#253 2019-12-14 03:23:34

Re: chromium: hardware video acceleration with VA-API

#254 2019-12-14 14:25:30

Re: chromium: hardware video acceleration with VA-API

#255 2019-12-15 05:34:57

Re: chromium: hardware video acceleration with VA-API

#256 2019-12-15 09:45:08

Re: chromium: hardware video acceleration with VA-API

#257 2019-12-15 11:36:36

Re: chromium: hardware video acceleration with VA-API

#258 2019-12-15 12:32:22

Re: chromium: hardware video acceleration with VA-API

#259 2019-12-15 17:56:23

Re: chromium: hardware video acceleration with VA-API

#260 2019-12-15 18:16:12

Re: chromium: hardware video acceleration with VA-API

#261 2019-12-15 20:07:58

Re: chromium: hardware video acceleration with VA-API

#262 2019-12-15 22:02:51

Re: chromium: hardware video acceleration with VA-API

#263 2019-12-16 16:13:57

Re: chromium: hardware video acceleration with VA-API

#264 2019-12-16 16:20:25

Re: chromium: hardware video acceleration with VA-API

#265 2019-12-16 17:05:06

Re: chromium: hardware video acceleration with VA-API

#266 2019-12-16 17:14:54

Re: chromium: hardware video acceleration with VA-API

#267 2019-12-17 03:32:09

Re: chromium: hardware video acceleration with VA-API

#268 2019-12-22 15:54:07

Re: chromium: hardware video acceleration with VA-API

#269 2019-12-23 00:19:42

Re: chromium: hardware video acceleration with VA-API

#270 2019-12-23 03:53:28

Re: chromium: hardware video acceleration with VA-API

#271 2019-12-23 14:41:23

Re: chromium: hardware video acceleration with VA-API

#272 2019-12-25 03:26:31

Re: chromium: hardware video acceleration with VA-API

#273 2020-01-10 07:03:46

Re: chromium: hardware video acceleration with VA-API

#274 2020-01-10 09:22:46

Re: chromium: hardware video acceleration with VA-API

#275 2020-01-10 10:04:42

Re: chromium: hardware video acceleration with VA-API

Board footer