New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 463440 link

Starred by 62 users

Issue metadata

Status: WontFix
Closed: Mar 2015
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug

Show other hotlists

Hotlists containing this issue:

Sign in to add a comment

GPUVideoDecode on Linux is impossible without patching.

Reported by, Mar 3 2015

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.111 Safari/537.36 OPR/27.0.1689.69

Example URL:

Steps to reproduce the problem:
1. open a page with a H264 video with an Intel GPU (SandyBridge++) 
2. the CPU is consuming more than few %

What is the expected behavior?
Chromium should include a flasg or a mechanism to enable VAVDA on Linux, so the GPU could be used to decode H264 HTML5 video

this old review seems to show that it was enabled before :

What went wrong?
this GPUVideoDecode code is disabled for Linux but enabled for ChromeOS which is really unfair.

Did this work before? N/A 

Is it a problem with Flash or HTML5? HTML5

Does this work in other browsers? Yes 

Chrome version: 40.0.2214.111  Channel: stable
OS Version: Ubuntu 14.04
Flash Version: NONE

Not enabling this will lead to forks...
Showing comments 14 - 113 of 113 Older

Comment 14 by Deleted ...@, Mar 18 2015


I am trying to use your patch under ARM (BananaPi hardware), and I've got a compilation error :

../../content/common/sandbox_linux/ fatal error: 'content/common/gpu/media/va_stubs.h' file not found
#include "content/common/gpu/media/va_stubs.h"
1 error generated.
[14512/18409] CXX obj/content/common/sandbox_linux/content.sandbox_seccomp_bpf_linux.o
ninja: build stopped: subcommand failed.

Would it be because of this part of the patch :

--- beta.vivid.orig/content/content_gpu.gypi	2015-03-12 09:14:22.300951127 -0400
+++ beta.vivid/content/content_gpu.gypi	2015-03-12 09:14:22.292951241 -0400
@@ -39,7 +39,7 @@
-    ['target_arch!="arm" and chromeos == 1', {
+    ['target_arch!="arm" and (chromeos == 1 or desktop_linux == 1)', {
       'include_dirs': [

I am completely newbie, but I dont understand why there "target_arch != 'arm'". Does this mean that ARM does not use "thrid_party/libva" ? why ?

Comment 15 by, Jul 5 2015


Could you get updated patch that works with latest git? I tried fiddling the one provided but compilation fails.



Comment 16 by, Sep 2 2015

5 months Later, situation is even worse ... the patchs we used in May 2015 don't work anymore on Linux with current chromium.

Please chromium people, explain us why so much hate for the linux platform

Comment 17 by, Oct 15 2015

Is there a reason this is still only exposed at build time rather than through a flag? VA-API is actually very stable and performant in recent Mesa, and I really shouldn't have to build Chromium myself to get stutter-free 1080p under a 4300Y...
Can't agree more with #16.
I also urgently request this feature!!!

This is a hard reason to change at least the browser.
I agree with #16 ... #19
Please make this available in linux! I have tried Saikrishna Arcot PPA both beta and dev but none of them works :( The Libva library gets loaded but it is not using it.

Can i make this happen with on older version of chrome? I only want to use it for my htpc running Netflix.

Kind regards Staffan
I am trying with chromium from on Ubuntu 14.04; I have a NVidia GTX560Ti with NVidia drivers, with VDPAU and VA-API working perfectly.
Playing a 1080p h264 video with mplayer or gst-play-1.0 only takes me 3% CPU, while the same video on youtube with chromium about 50/60 in chromium.
Also tried with –no-sandbox with no luck.

Comment 23 by, Feb 18 2016

Hello chromium team.

It's now several years that we cannnot use HW GPU decoding on chrome on Linux although it works really well.

If you don't want to support it out of the box for some obscur reason,it's your right, but please, let us activate it through a Flag ? 

I agree that at least hardware decoding flag should be available.
I use Chromium-dev on Manjaro (Arch Linux) and it works very well thanks to a patch that enables the video decoding.

Comment 26 by, Jun 6 2016

Where the package for Arch with the patch is available?
it is on AUR but you can download the binary pakage from ArchCN (only 64 bit):
Just tried again, with chromium 52.0.2743.19-0ubuntu1~ppa1~16.04.1 from chromium-dev PPA on Ubuntu 16.04, no success.

Which version are you using on Manjaro? Do you run it with some special switches? Which video do you play?

Comment 29 by, Jun 6 2016

It is patched version, available at AUR above
I see there are 2 versions, 52.0.2743.10 and 53.0.2756.0.
Which one are you using?
Do you run it with some special switches?
Which video do you play?

Comment 31 by, Jun 6 2016

I have installed 53.0 from this AUR and it works fine (tested on video with flash player)
How about HTML5 videos...?
Usually va-api works with h264 videos, so for youtube you should install an extension to use only h264 video on yt like this

Tried with 52.0.2743 on Ubuntu with youtube videos with h264ify with no luck ufortunately.
I installed Manjaro 16.06 to give it a try, but it does not work for me.
I installed the 53.0.2756 binary package from and h264ify extension.
Mplayer and gst-play-1.0 works perfectly with VDPAU acceleration (as in Ubuntu).
Launching chromium-dev without options give me the first log (FPE_INTDIV signal) and then "Failed to launch GPU process".
Launching with --no-sandbox gives me the second log (vaQuerySurfaceAttributes failed VA error: invalid parameter).
Youtube videos play, but not accelerated.
So for me no hw acceleration, even on Manjaro unfortunately.
2.4 KB View Download
3.7 KB View Download
54.1 KB View Download
what GPU do you have Davide?
NVidia GTX 560 Ti
you should intall libva-vdpau-driver

then install and run from the console vdpauinfo to check if vdpau is activated.

vdpau and va-vdpau are correctly installed, as said before mplayer and gst-play-1.0 are working perfectly with hw acceleration.

vainfo in fact reports this

libva info: VA-API version 0.39.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/dri/
libva info: Found init function __vaDriverInit_0_35
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.39 (libva 1.7.0)
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
      VAProfileH264Baseline           :	VAEntrypointVLD
      VAProfileH264Main               :	VAEntrypointVLD
      VAProfileH264High               :	VAEntrypointVLD
      VAProfileVC1Simple              :	VAEntrypointVLD
      VAProfileVC1Main                :	VAEntrypointVLD
      VAProfileVC1Advanced            :	VAEntrypointVLD

David, I have a package in the AUR, and also a repository as well.  See if that is able to work for you:
Repo details are in my pinned post.
no change for me unfortunately, I always get the "Received signal 8 FPE_INTDIV signal" (see my previous post, log.txt attachment)
too hate for linux users, it is incredible that any browser has hardware acceleration in linux, but chrome os android windows and mac yes when chrome os uses vaapi like others, this feature has to be in flag, there isn't any type of reason not to put there

Comment 43 by, Aug 16 2016

The package that enables this broke again :(

It really is a pain to have to rebuild the browser every so often just to get this one flag toggled on.
you can try chromium-dev from archlinuxcn;O=D

Btw now it requires the old libvpx 1.5 you should wait for new version or compile libvpx 1.5 by yourself. I did it modifing the pkgbuild of (check the attached file)
1.2 KB View Download

Comment 45 by, Jun 15 2017

Hello , 2 years later ...

Some important info to check that a patched version is really using the GPUVideoDecoder ( You know the one that chromium people said it would not work ...)

go to chrome://media-internals, click on the button representing the player, and check to see if the video_decoder property is GpuVideoDecoder. If not, then hardware video decoding isn't being used.
I created AUR package chromium-vaapi-bin to host pre-compiled binaries, hopefully with the help from current maintainers of chromium-vaapi we'll be able to keep both of them up to date.

Shame on Chromium developers for refusing to accept this patch that the community has developed and tested over the past few years. It clearly works, improves performance and increases battery life, and certainly deserves to be at least in the chrome://flags section - the importance and impact of this improvement is way bigger than some of the existing flags over there, like "Switch 'Save as' menu labels to 'Download' #saveas-menu-text-experiment".
It's 2017, really... It's time to add this feature: add it disabled or as experimental to be switched on by a flag but start working on it please.
it is in the way my friend :) there ar an official patch working with amd an intel, with nvidia I don't know

Comment 50 by, Sep 4 2017

Even after 2 years ( I'm the OP) , I'm would be really happy to this progress on this , even if we need to wait 6 more months to see this in stable. 

As vaapi now support VP8/VP9 I guess nothing should stop us to hwdecode youtube dash VP9 on kabylake ? 

That would change everything
Oh my god, I didn't know, but it works! I have a Kaby Lake i7-7820HQ, and I can watch a youtube video in 4k with VP9 with hardware acceleration using that patch. See attached screenshot.
203 KB View Download

Comment 52 by, Sep 4 2017

@maxiumbaz : I really love this picture ! :-) 

Did you use the patch 532294 to achive this ? What CPU load do you get ? 
Yes, I used the patch 532294 (version 10 of it). The CPU load is around 12% when the video is playing in full screen.

Comment 54 by, Sep 4 2017

Thanks it is what I dream for some time 

Comment 55 Deleted

Comment 56 by, Oct 3 2017

@rath : it's not related to your widevine problem, we talk about GPU decode here 

Comment 57 by, Oct 3 2017

My apologies, I pasted the wrong RHBZ link. The correct one is .

I deleted the comment with the wrong link, too.
+1 for upstreaming that flag for VA-API
the patch seems to be rather simple and not change much from code for ChromeOS
On my system the decoding works on Intel GPU on my tablet with linux

Im really interested in this feature. How do I get this patch working on iMX6.0 with Debian stretch. I downloaded chromium and i see the video performance is really bad. How do I get the patch version?
I also success on making gpu decode in chromium. This option should be mode into  stable chromium
I can use HW acceleration with video in amd and intel without problems, when will it move to stable?

Comment 63 Deleted

Albert and Kidult, which version of chromium are you using and which API did you use to have HW acceleration? VDPAU, VAAPI?
+piman any opinion on this issue and associated change?
I don't think we should do this. We have no intention of releasing this into the product, so this is dead weight with increased maintenance cost.
piman could you elaborate why you have no intention to merge HW acceleration into the product when it works so well for many people?
Our goal is to have a Stable and secure browser first, and a GPU-accelerated one second, when possible. As we found out time and again, any sort of GPU acceleration has a lot of maintenance associated with it, between the multitude of configurations our users run, the general lack of quality of drivers (in particular on Linux), and the constant stream of incoming issue due to new hardware, driver, or distribution release. Many of these issues are not even directly attributable to this or that acceleration feature (e.g. causing random memory corruption or GPU hangs), so even investigating to narrow down a blacklist entry is significant non-trivial work.
As we do not have the resources to commit to dealing with this continued incoming stream of issues, and we don't want to compromise the first goal (stable and secure browser), our choice is not to enable these acceleration features on Linux.
I can understand the problem of the maintenance, but not the problem of drivers because in linux there is good drivers now, and probably since 3 years ago..
Driver support is still a problem.
Current patch only supports VAAPI so it works with AMD and Intel out of box. To get it working with Nvidia you'll need a patched libva-vdpau-driver
Another problem is that codec support is limited with vdpau. VP9 and H265 (other than main profiles) on Nvidia is available in proprietary API NVDEC. As a result, only H264 decoding is available in patched Chromium.
Also, hardware decoding of VP9 on AMD is only available in APUs with Vega graphics, discrete AMD GPUs does not supports it.
You Google guys always kill me ...

Le lun. 1 oct. 2018 à 21:05, yurish… via monorail <> a écrit :
#71 - ChromeOS with ~0.3% desktop market share matters more than ~2% linux users :) It's really sad my 4-year-old android phone with 2gb ram and a shitty mobile CPU+GPU runs chrome(ium) smooth as silk and my last-gen linux desktop struggles to play a 1080p video and stutters scrolling single opened tab. You don't need to rebuild the wheel. There's gstreamer, vlc, patched ffmpeg and other backends you could use that implemented vaapi AND vdpau successfully for years. Maybe it would be easier to allow us to use those rather than fighting the shitty driver and va libs directly.
But this would be behind a flag. Doesn't that alleviate your concerns about compatibility issues and maintenance overhead? If it doesn't work for someone they will know they just have to disable it.

Or would you consider accepting a merge request that has a whitelist perhaps? What would your criteria be to consider a given setup stable and secure? I understand you don't want to prioritise this but perhaps others can make some progress in the meanwhile if they know how to help.
The choice of not enabling acceleration on Linux is just ridiculous. For example I have an old computer with Intel core 2 duo and an old Nvidia card (supports H264 decoding). In any Linux distro, I simply can't watch any Youtube video because it does not support VP9 or H264 hardware decoding. It is impossible to have smooth video playback regardless of the codec used. So disabling HW acceleration is not a solution. 
ChromeOS is Linux.

Il Lun 1 Ott 2018, 22:37 sidboymo… via monorail <> ha scritto:
We should fork  it , gnu/linux deserve better than that!

Le lun. 1 oct. 2018 à 22:37, sidboymo… via monorail <> a écrit :
Code behind a flag still has a cost:
- additional binary size
- build time
- developer cost to keep it at least building, and possibly extra cost due to necessary abstractions
- risks associated with dead code (see e.g. "Knight Capital")
- overhead from bug reports by users who turn on the flag

Some of these may seem trivial. They do add up, across many features and integrated over time. 
This is not a burden we want to take on, as we don't have plans to release the feature in the product, or otherwise need it for development.

If someone is interested in taking on the maintenance cost themselves, they are free to maintain the patch and/or a fork.
i can understand this:
not to enable video decoding with NVIDIA and AMD propietary

I cant not understand:
Not to enable video decoding through VAAPI in intel, nvidia and amd with open source drivers

Why? because I have used since I could the chromium patched, and not before but now the patch function with AMD and Intel, very stable for me, and for all the pc's I tried.. in my dual core 10 years old too, it is not a problem of good drivers(AKA not nvidia), it is a problem of standards of nvidia, simply, enable it for amd and intel, no more

PD: I am using aur version of chromium-vaapi-bin
You are very funny....

Le lun. 1 oct. 2018 à 22:59, pi… via monorail <> a écrit :
Guys that use the vaapi patch, please try to play a video with vaapi and right click the page repeatedly really fast, or click the main menu repeatedly. My video thread gpu crashes when I do that but I suspect the fault is in the patched libva-vdpau-driver-chromium or even the nvidia driver. I have an nvidia card, if you don't trigger the bug with intel/amd let me know so I can try to debug & fix the patched libva. Attached video sample, in the first crash it downgrades quality, second crash is definitive. Only UI interactions do that, I can open multiple 60fps 1080p videos and it stays smooth. The logged error is: [25585:25585:1001/] : Failed putting surface to pixmap VA error: operation failed
9.7 MB View Download
#75 Google disagrees
@Comment 77 I cannot agree with the reasoning of that decision considering the Pros and Cons especially not taking the user impact into account. The burden mentioned in the mentioned comment are valid concerns from the developer side, I admit that. But there is a bigger picture, this decision is holding back the Linux desktop experience in a significant way. Think of all the linux notebook users out there with Intel/AMD graphics chips who are now dependent on custom patched Chromium builds to have a decent web video experience. There are some distributions which already ship chromium with these patches applied (e.g. Suse Tumbleweed), but on others (e.g. Solus) there is no easy way for an average user to get a patched package they can easily use.

Considering that this is a major feature for quite a few users, breaking the hw video acceleration should put pressure on the driver and library developers to fix things, right? 
> Code behind a flag still has a cost

Lack of hardware acceleration have higher cost for Chrome users by wasting tablet or laptop battery, or not availability of certain video resolutions.

For example, I had to switch 1080p/60fps YouTube videos to 480p/24fps because 720p/60fps and 1080p/60fps is stutter on my $3500 laptop due to lack of hardware video decoding in Chrome - that just ridiculous! 

You already have Intel hardware video decoding tested and working in ChromeOS. Make it available in Chrome too. 2% or Linux users is more matter than 0.3% of ChromeOS users. 
I'd like to remind Google that enabling HW acceleration is also ecollogicaly relevant considering power usage reduction.
Yes but Google does not care about ecology.

They just want to be sure that gnulinux cannot compete with their os...

Le mer. 3 oct. 2018 à 06:09, bmil… via monorail <> a écrit :
The patch adds an experimental feature flag. It's not meant to be enabled by default, so I don't really get why it won't be merged.
From - "Small changes can make a big impact on our planet"
I think instead of criticizing Google we should just ask them to honor their own commitments.
I don't understand why not to merge a patch that have a toggle to be used.. It has some cost, yes, I know it, but.. isn't it better than to rebuild chromiuim with a patch simply.. to have HW accelerated?! something that is enabled by default in Windows.. in chromeos... ejem, chrome os uses Linux.. and vaapi, the patch is based on chrome os ones.. 
"Our goal is to have a Stable and secure browser first, and a GPU-accelerated one second, when possible. As we found out time and again, any sort of GPU acceleration has a lot of maintenance associated with it, between the multitude of configurations our users run, the general lack of quality of drivers (in particular on Linux), and the constant stream of incoming issue due to new hardware, driver, or distribution release. Many of these issues are not even directly attributable to this or that acceleration feature (e.g. causing random memory corruption or GPU hangs), so even investigating to narrow down a blacklist entry is significant non-trivial work.
As we do not have the resources to commit to dealing with this continued incoming stream of issues, and we don't want to compromise the first goal (stable and secure browser), our choice is not to enable these acceleration features on Linux."

Well this decision seems to be based on past experience - Linux GPU drivers have improved considerably in the past few years. They pass Khronos' OpenGL and Vulkan CTS, and have been proven to be both stable and performant. Your argument does not hold, especially since ChromeOS uses (AFAIK) the exact same open source driver for Chromebooks with Intel GPUs. There shouldn't be any objection to merging in code, especially when it's disabled by default and hidden behind a feature flag.
Your arguments don't hold.
GPU drivers are good nowadays, at least the AMD and Intel ones.
You're right about Nvidia, but nobody is asking to support their proprietary standards: just blacklist them.
Your is also an environmental hostile behaviour: you're wasting tons of power and polluting our planet for no reason.
Not talking about the awful experience which you're forcing your users to. Hardware decoding is not simply an alternative: it's mandatory for a smooth playback.
Using bad-faith vendors who don't respect open source to hold power-consumption-respectful obvious clear progress back is a bad look & ya'll should re-assess. 

This is a really bad look. There's nothing holding this back but your own willpower & from our view you're willing to toss out Linux user's battery life because one vendor is a bad apple.

Support VA-API. Enable this.

Comment 93 Deleted

I think that google's answer is in bad faith.

- The feature can be off by default with a big warning if deemed necessary.

- Opensource drivers are good nowadays and Google has at least as much ressources as the guys from Valve (who do a great job on Mesa) to submit patches there too if needed. 

- The stuff is good enough to use it in ChromeOS so they should morally go the extra mile and make is generally available on linux distros too.

- No need to support non-opensource drivers (nvidia can be blacklisted) at the same time, just enable what is already know to work. 

That feature is a must for usability and power usage. Google is disapointing there.

Another issue that prevented the use of VA-API on Linux was that libva was regularly breaking its own ABI across releases. That point seems to have improved since 2.0.0.

Also for Chromium OS we are still carrying out-of-tree patches for the libva intel driver:

The libva that comes with Linux distros will not have these patches. What is the behavior going to be? If we could make it so that Chromium OS can run on an unpatched libva driver, we could at least have more confidence that things won't break horribly on Linux.
Why are these Chromium OS libva patches not being upstreamed? Are they blocked by upstream for technical reasons? Can't they be reworked if that's the case? 

It seems to be Google's responsibility to minimize divergence from upstream and produce patches with the aim of upstreaming them.
> Our goal is to have a Stable and secure browser first

Well I don't think shuttering video with very high cpu usage and power consumption would be consider as 'stable' imo.

The main issue is, Linux has many video acceleration apis. It's impossible to implement all of them. I can understand that. However I have a separate plan for this.
Use GStreamer to play media streams in chromium. A Media Process which is own by the Browser Process and creates players on-demand. Any Video tag will be backed by a GStreamer pipeline that lives in the Media Process.

Please look at here. It's by samsung.

This will enable packaging chromium to certain linux distributions where proprietary code is prohibited and in return reduce the overall size and maintainance cost of chromium.

The bugs specific in this case will be targetted at GStreamer only. Video will have harware acceleration too. 
How the video will be decoded and processed are provided in their repo's README.
Having spent a lot of time getting VA-API decoding on Intel working and stable for Ubuntu in 2017, I too am disappointed by "WontFix". However, I do fully agree that the radeon and nvidia driver options are not ready and stable. For this reason, in Ubuntu we only recommend using VA-API with Intel GPUs. This is known to be stable and reliable in Ubuntu versions 17.10, 18.04 and now 18.10 (

I suggest as a way forward in Ubuntu 19.04 we might auto-install only the known stable driver and ensure no others are. In this way most Linux users (since most Linux users have Intel GPUs only) will be supported still. And the problems with radeon and nvidia will be avoided since the absence of a VA-API driver should cause the app the fall back to software decoding.

There are no major issues with AMD and VA-API. There have been issues with
the experimental switch to AMDGPU for GCN 1.0/1.1, but it's just a matter
of blacklisting the faulty ones. R600 also has some potential issues, but
it's very old hardware. Just ask AMD and they will provide all the
informations necessary to avoid potential troubles.

Il gio 4 ott 2018, 08:01 daniel.v… via monorail <> ha scritto:
OK. My known problems with radeon might be confined to gstreamer-vaapi ( I have not confirmed that yet.

However what we really want is drivers with zero user-facing bugs. And comment #99 mentions more than zero for AMD.
You will never get zero issues: users can patch their drivers, use git
snapshots, experimental drivers... What you want is the vast majority to
work without issues, people with strange setups are usually smart enough to
know what's the culprit. R600 has some potential issues? Just blacklist it.
Easy win. Other AMD users will still be able to enjoy acceleration. If this
is the real blocker an AMD employee can easily give you a list of what to
blacklist or even what to whitelist to get near zero issues.

Il gio 4 ott 2018, 09:02 daniel.v… via monorail <> ha scritto:
OK, so if you want, you can potentially break half the Internet by making touch events passive by default just to advertise faster scrolling on your Android platform (which is Linux behind the scenes), and you can add GPU video decoding to your own ChromeOS (which is also Linux btw), but when it comes to us actual Linux users we get a second-class treatment. I've been reading countless articles about how the Linux graphics driver scene has never been better, and also experience it first-hand, but I just don't get why you won't mainline this (don't even need to enable it by default, just put it behind a flag, we have wasted countless hours in chrome://flags to figure it out)
Is anyone from Chromium project could comment on Canonical proposition in Comment 98?
Hello I'm the OP.

the patch is tracked here : 

Intel, canonical and others have asked such a feature for YEARS , the new patch was submitted one year ago.

So don't expect any effort from Googlers, they just obey their master blindly.

We need to move on , forking is the way, a new package in debian for example would benefit to all distros.

I would love the idea of a fork, because Google's behaviour is starting to
be really annoying for Linux users. But in order to be useful we need all
the major distros to agree, otherwise it's better to just ship the patch
like Suse does.

Il ven 5 ott 2018, 11:24 cont… via monorail <> ha scritto:
I did not know that Suse shipped the patch in their chromium package.

We spoke with Olivier tilloy from Canonical but we agree that shipping the patch in Ubuntu was a risky and costly move for now at least.
The root cause of this issue is proprietary drivers, and not rolling release models.

I would simply support open source drivers only, on their latest stable version.
the root cause is not the proprietary drivers, it is the fault of standars in nvidia's one
why not to fork chromium and create your own browser with your own patches?
There actually is a fork, but an upstream fix should always be preferred. Maybe at some point the fork maintainer will stop maintaining it.
I've been using the saiarcot895 beta for two months now in ubuntu (on a Thinkpad T480 pure intel graphics), it's been flawless in both the ubuntu desktop and kde neon. 

what is this patch?: "Enable mojo video decoders by default on Linux desktop if use_vaapi is true"
PS The Fedora devs seems to have just decided to enable hardware decoding in their build of Chromium.
Showing comments 14 - 113 of 113 Older

Sign in to add a comment