Works great in mpv (I know, I wrote it). No one should be using mplayer in this day and age.
What works great in mpv, VDPAU or NVDEC? It’s beside the point since mpv doesn’t support UPNP mpeg2 streams. For that vlc is needed. Unfortunately I discovered that nvidia HW decoding is broken on my platform so even vlc doesn’t help. VLC built with NVDEC support would be a godsend if it works.
nvdec works in mpv. Works with Vulkan too.
I still argue that it doesn’t work great, or doesn’t actually “work”.
I was under impression that the whole idea is to save power or get better performance by offloading decoding to the GPU.
When the computer draws 50% more power with NVDEC compared to CPU decoding, I say it’s NOT doing what it’s supposed to do :)
My undestaing is that using EGL/dma-buf would only benfit users using DRM (Wayland) instead of X11 (Xorg).
Currently Wayland usage with NVIDIA GPU is not widely supported/spread, for the whole EGLStreams/allocator situation you mentioned.
I’m speculating here but I would say that all current X11 apps/browsers using libva use GLX instead of EGL, is that correct?
So, if this is true, it looks to me that even if GLX part of libva looks it’s been deprecated and given the current NVIDIA/EGLStreams situation, it might make sense to implement libva GLX backend for nvenc+nvdec. At least until the EGLStreams/allocator situation is been solved.
For me it would be nice to take a look to your code and maybe continue from what you have done if it feels OK to you and if I can manage to have enough time to finish it.
Thanks in advance,
EGL works just fine in X.
Incorrect. They use EGL. Well, I have no clue what Chromium does, but mpv, VLC, Kodi all use EGL.
In my computer using Xorg at least Chromium, mpv and VLC, they all use GLX.
I don’t have Kodi installed but I assume it works similar to the other you mentioned.
The ones I tested they support both GLX and EGL, but they use GLX by default.
As an example: to switch chromium use the flag “–use-gl”, to switch mpv use the flag “–gpu-context”, VLC I assume it will work with the flag “–vout”.
So the point is that currently programs use GLX by default in Xorg.
VLC does VAAPI only with EGL. mpv used to have VAAPI/GLX, but it was removed, because it was a hack basically. So while mpv defaults to GLX, you won’t get VAAPI running with that, you need --gpu-context=x11egl (well, there’s also --vo=vaapi which doesn’t use GL at all). Kodi is similar to mpv, it used to have the same GLX hack, but they also removed it.
Just to reinforce this point - the GLX interop was horrible and had bad performance characteristics, so everyone moved to the EGL interop as quickly as they could. If you leave mpv default config alone, it should automatically prefer x11egl and vaapi at this point - you’d only use GLX if you forced it.
Separately, since I last posted in this thread, I did go ahead and implement a proof-of-concept vaapi-vulkan interop for mpv and it works as I expected it would - you use the same DMA_BUF export from vaapi and then do an import on the vulkan side. It’s not shippable as there’s a missing vulkan extension that’s required to communicate the buffer memory layout. Without it, you have to hope for the best, and it happens to work, on Intel, for NV12 and P010 which are the primary decoded-video formats.
But the end result is that, as expected, the nvidia and vaapi mechanisms are both completely different, even though both are fully standards-compliant. Aren’t standards great?
Not on AMD. mpv checks the existence of GL_NV_vdpau_interop to decide between GLX and EGL. And well, the AMD driver implements GL_NV_vdpau_interop, so GLX gets chosen and loading VAAPI fails. There’s a PR open on mpv’s github to change this and always prefer EGL (forcing Nvidia VDPAU users to specify gpu-context=x11 to force GLX), but there’s opposition to merging that PR. https://github.com/mpv-player/mpv/pull/5298
Perhaps mpv’s GLX/EGL check should probe whether the Nvidia driver is in use instead of probing for the extension, but then NVDEC can use EGL, it’s only VDPAU that requires GLX.
You are right. I forgot about that PR - it’s been a long time and I don’t think it’s on anyone’s radar anymore. My personal opinion is we should flip it, given how VDPAU is less and less useful.
But on the other hand, I’m surprised the AMD driver is still claiming to support vdpau. Everyone uses vaapi with it now right? I’d have thought they’d have removed vdpau so they can simplify their internal code.
It’s also possible to dig a little deeper and look at vendor strings to decide whether to use GLX or EGL if you really wanted to. That seems like the easiest way to keep the most people happy.
give a try to qmplay2 …it supporst vdpau and cuvid decoding …
Hey, @NVIDIA, any update on this?
I’ve noticed a new version of the VDPAU library with VP9 support, which is nice, although no version of the NVIDIA driver actually supports that yet.
Any update on this? Seems Firefox is getting closer to supporting VA-API.
Is there any update on this? Firefox 80 now has support for VA-API, although I can’t check if it’s actually working.
Now that GBM has been added to the 495 drivers, would we be seeing Wayland support for VDPAU as well, or VA-API for Nvidia cards? It seems like quite a major not to have any hardware decoding capabilities in any major browser. NVDEC also still has the annoying behavior of switching the entire GPU to the P2 state just to decode a simple video.
Funny you should bring this up. I’ve just been taking a look into it again now that I’m on 495. In theory the only part left to prove works is exporting a buffer from CUDA that can be imported via the DMA-BUF mechanism. CUDA supports exporting an fd, but as to if that’ll work with eglCreateImage I’m doubtful. @aplattner/@aritger Should this work?
I have however expanded my little test library to include all the codecs I can. VA-API isn’t a particular good fit for NVDEC, given that’s VA-API is just as designed for Intel hardware as NVDEC is for NVIDIA hardware.
I’ll let you know how my testing goes.
Quick update, it’s working:
Unfortunately it’s only working for around 64 frames and then crashes, so I’m clearly running out of some resource, but things are looking good.
This looks fantastic. Would you mind sharing that Library? Maybe upload it to your GitHub?
I’ve finally uploaded the library to Github, and posted about it here.