Chrome Support #5
Comments
|
I haven't tried it with Chrome yet, I wasn't aware that VA-API support had been added, or is it a patched version? It shouldn't be too hard to add support, it's unlikely to do anything drastically different from Firefox. |
|
Running with |
|
@elFarto I think it's a flag that needs to be enabled on compile time. But I think most distributions have it enabled. Not sure how well it works with the new Ozone layer. |
|
Getting the same errors as @hf29h8sh321 in Brave, which has VA-API enabled by default in their Linux builds. Would love Chromium-based browser support here as well. Thanks! |
|
Anyone have any idea where a change would have to be made for this to work? Looks like the error is logged from chromium itself, but I suspect the issue lies within some part of vaapi not bring implemented in this lib. I will do some digging on this when I get some time and would appreciate any pointers anyone may have. |
|
I'm focusing more on getting the library working well under Firefox, so this isn't a high priority at the moment. The first thing to look at is where the FillProfileInfo_Locked message is logged, and see what it's looking for from the VA-API implementation. Once you can see why it's failing (likely a missing attribute, or function not implemented) we can look about fixing that. |
|
Cool, thanks, I will start there once I have repro-d the errors logged in this issue. TBH i am hoping its just incorrect chromium flags as they are a mess and constantly changing. Congrats on the first release of this btw - its a potential game changer until Vulkan saves us all. |
Looks like the problem is with nvidia-vaapi-driver/src/vabackend.c Line 452 in 5ddf7ca you can bypass this by hard coding values (very hacky) attrib_list->type == VAConfigAttribRTFormat;
attrib_list->value = VA_RT_FORMAT_YUV420;
*num_attribs = 1;moreover vaCreateContext will fail because chrome doesn't pass VASurfaceIDs to vaCreateContext. Also chromium uses |
|
If chromium (Note that Google never build Chrome with vaapi support) is still using |
|
chrome support would be cool for playing stadia in 4k |
|
Ok, the missing attribute is simple to fix, the surface IDs not being passed in is a bit more problematic, and the use of vaPutSurface is just weird. I think we can work around the surface IDs not being passed in, as we don't really need them, they're just assigned a picture number to be used later. This could be move to a dynamic allocation. We would then just need to come up with some reasonable defaults for the missing ulNumDecodeSurfaces and ulNumOutputSurfaces fields, which shouldn't be too hard (I already had a note to look at that anyway). vaPutSurface is going to be hard to get working if they're using it. vaPutImage is also difficult to work around. As noted above we don't really have any surfaces, they're all managed for us, so to 'put' something into a surface is not an action we can do. We could try stubbing those methods to return successful but not actually do anything and see what that breaks. I noticed that their DMA-BUF export code seems to throw away the DRM modifiers, and that's a blocker. The NVIDIA driver requires they be passed into the import method (it's the same thing I've fixed in Firefox and MPV). I also noticed some protected playback stuff, that's almost certainly never going to work, hopefully it doesn't use that by default. |
|
Looks like vaPutSurface will not be used when you start chromium with |
|
I've made a couple of changes to the library to try and support Chrome better, but I'm not having much luck testing it. Chrome gives me a weird EGL error when I try and start it. You'll likely need to use NVD_LOG=filename as it stdout doesn't get displayed. |
Testing on 441c03d, I think it still fails because of missing VAProfileNone #5 (comment) |
|
Google Chrome Beta crashes a few times with |
|
Chrome Beta actually disables GPU entirely when this is loaded. Definitely something wrong. |
|
@helloer A couple of questions. Which chromium build are you running? and are you running this under Wayland? I'm getting these errors at the moment, attempting to run it under X11: |
Chromium 97.0.4692.99 Arch Linux under X11. Maybe it's due to https://github.com/archlinux/svntogit-packages/blob/packages/chromium/trunk/unexpire-accelerated-video-decode-flag.patch? |
|
I've spent a few hours working on this today and managed to get...not far. I've discovered that XFCE's display composition is what was causing the the EGL_BAD_MATCH errors (I think). Disabling that got me to helloer's error. I hacked in some code to pretend we support VAProfileVideoProc, then got to this line. I've checked the code in on the chrome_support branch. |
I get the same thing on Gnome 42 on X11 with a GTX 1080 on 510.60.02 with GChrome 100 Not sure if I need If I open if it means anything |
|
Hoping this could work on chrome some day. There's already vdpau backend implementation of va-api working perfectly on chromium. It currently supports all h264 profiles & vp9-profile0 & uses VDAVideoDecoder. |
|
I've reworked some stuff and got Chromium on X11 (with desktop GL) support sort of working, but it's quite a hack and very inefficient, and the resulting image isn't quite the correct colour due to the library having to do the YUV -> RGB conversion. I would not recommend it for daily use. However, I'm having a problem getting Chromium on Wayland (with EGL) to even initialise VA-API. I'm using this command on Fedora 36/GNOME 42: But I see an output early on about DRM Prime not being supported. This seems to be the result of the wl_drm protocol on the display server returning the capabilities of 0. I can't find what's setting that value. Can some of you try launching chromium with VA-API and NVD_LOG=1 and see if it initialises the library on startup? Also, could you note which wayland compositor you're using. You don't specifically need this branch to test it, chromium will at least initialise the regular version. |
|
@elFarto Did you test your patches on xwayland with ozone enabled? I don't think egl will help with this because it has lot of other issues such as reduced gpu performance. Even if you make it work, no one gonna have chromium on egl backend. |
|
--ozone-platform=wayland is automatically passed with chromium-freeworld. Just tried regular chromium too, slightly different error: rather than: |
same thing on gchrome |
|
@elFarto I meant xwayland btw. Let ozone choose X11 as ozone backend & see if it really works. |
|
|
above was wayland. this is x11: |
|
It does look like there have been some changes to Chromium recently. The X11 backend is now trying to use DMA-BUFs which is good. However, there's another limitation, it requires a single fd be exported for both planes, which we can't currently do (I might be able to make the direct backend do it, but it runs into issues with smaller videos due to different modifiers). I did try some experiments with it, but didn't get too far. The Chromium issue is here, however it's been open a while now, so I don't know if it'll get fixed. |
|
Relevant CLs that recently landed:
So on nightly it should be enough to run with |
OK apparently I was wrong - some of the lingering issues are still there... |
|
I can confirm that the and then a VP9 youtube video that I tried decoded on my GPU too. Pretty great. Thanks to everyone who put in the work to get this done! 🎉 |
Can u also test if a 10bit hevc video would be decoded normally on a nvidia gpu? (For example, the following url) According to Chromium Issue Tracker, the issue should be already resolved, while on my amdgpu I can only get black output.. Also, if u want test whether an HEVC main (not HEVC main 10) video works or not, u may use the following link.. |
I can confirm that either! Great work @rmader ! |
Thanks, however most work was done by others. One important one was actually https://chromium-review.googlesource.com/c/chromium/src/+/5797623 which also paves some way to implement Wayland/KMS offloading in the future. |
See my better formatted comment belowI can also confirm that I am having success on Arch repo chromium with YouTube and the Apple video linked abovechrome://gpu reports the following Scrolling through the log output the only warnings I saw were: and @LuanVSO |
|
for me, angle=opengl only works on x11, only angle=Vulkan works on Wayland, but if try to enable video acceleration with Vulkan any video will be a transparent hole, and the window will have a lot of graphical glitches after trying to load a video (fedora 40 + chrome-beta 131) log of this command: |
I can replicate the black rectangle under Vulkan ANGLE with the following spammed to the log However, I had no issues with OpenGL ANGLE under Wayland, is it possible you're missing a dependency like egl-wayland |
|
Chrome also working finally!
|
|
I can't even get chromium started using |
|
It works with h264, I have never gotten the VP9 codec to work on youtube or whatever they use. It seems to work at first then it just falls back to CPU decoding. |
|
Just to make it a bit easier to see what's going on, could everyone who's tested this please copy the below form, fill it out and post it - Chromium source:
- Chromium package:
- X11/Wayland:
- Desktop Environment and version:
- Driver package:
- Driver Version:
- GPU Model:
The following comes from chrome://flags/
List of non-default flags:
-
The following comes from chrome://gpu
- Video Decode:
- Video Encode:
- Chrome version:
- Command Line:
- GL implementation parts:
- Video Acceleration Information
<!--
Paste the table here
-->
<details>
<summary>Paste Logs Below</summary>
<pre><code>
Put your logs here, don't mind the HTML, it makes the text collapse
</pre></code>
</details> |
The following comes from chrome://flags/ List of non-default flags: None The following comes from chrome://gpu
Paste Logs Below |
The following comes from chrome://flags/ List of non-default flags:
The following comes from chrome://gpu
Paste Logs Belowi do have egl-wayland and egl-gbm installed: |
|
i've figured it out, had to disable the AMD igpu in the bios and now opengl works fine |
|
At least it's working the vast majority of the time for me now.
The following comes from chrome://flags/ List of non-default flags:
The following comes from chrome://gpu
Decoding : Paste Logs Below
|
@BRS5672023, it plays, decodes in hardware, and draws to the display, but it's not smooth at all. constant, serious stuttering prints like these are constantly spamming the log while the video is playing/stuttering: https://test-videos.co.uk/vids/bigbuckbunny/mp4/h265/1080/Big_Buck_Bunny_1080_10s_1MB.mp4 works as expected |
@LuanVSO : |
The following comes from chrome://flags/ List of non-default flags: The following comes from chrome://gpu
Paste Logs Belowmy full |
|
for me HEVC and VP9 is flawless, it is better than amd driver even but AV1 fails and falls back to cpu decoding Paste Logs Below |
|
This video falls back to cpu decode if you go higher resolution. Or if it was this one.. Can't check right now |
Yeah, same for me. It works in 1440p, but then when I go up to 2160p it craps out (falling back to CPU decoding) like this: |
|
twitch ads breaks it as well, at the end of the ad it will keep switching between the last two frames of the ad instead of playing the stream, no logs for this one unfortunately |
Nice find, regarding the max resolution. I tried it here as well, and 1440p works, 2160p falls back to CPU. |
|
The resolution issue may be AV1-specific. If you don't prefer AV1 in your YouTube settings and get a VP9 4K stream, it will decode in hardware.
|
|
AV1 decode failure logs:
|
|
CUresult 1 is |
|
After the recent update to 131, I get this cryptic error in chrome://gpu and, of course, no hardware video dec accel. Downgrade to 130 and the problem doesn't exist anymore, so it looks like a regression. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
and others
Does this library support Chrome? If not, what would take to add support?
Awesome library. Looking forward to testing it. I'm happy to contribute!
The text was updated successfully, but these errors were encountered: