Issue with some kind of videos - only red channel showed

[RafaelLinux]

Please, to not repeat all info, could you see this thread?

I'll bet is related to your driver and maybe some other users have same one.

Thank you

[elFarto]

That's a very weird issue, I'm not sure how you end up with just the red channel. I've tried running QMPlay2 locally, but it just crashes with that video (which I think is a driver bug, I'll need to look into it).

Can you try running QMPlay2 with NVD_LOG=1 set and post the logs here?

[zaps166]

I can reproduce this issue on Nvidia laptop and QMPlay2. NVD_BACKEND=direct + Vulkan - some videos are OK, some videos are displaying green YUV screen, some other videos are very dark and displaying only some color channels (mostly red, some blue and very little green).

To use OpenGL with this driver on Nvidia I have to add QT_XCB_GL_INTEGRATION=xcb_egl, but it crashes. Without VA-API I always have black screen on Nvidia with EGL OpenGL + Qt - why? (I have to check it, but do you have any ideas?)

av_hwframe_transfer_data seems to be working correctly with NVD_BACKEND=direct.

---

logs.txt

Examples (this video)

1920x1080, VP9:

3840x2160, VP9:

[RafaelLinux]

That's a very weird issue, I'm not sure how you end up with just the red channel. I've tried running QMPlay2 locally, but it just crashes with that video (which I think is a driver bug, I'll need to look into it).

Can you try running QMPlay2 with NVD_LOG=1 set and post the logs here?

~> NVD_LOG=1 QMPlay2 > QMPlay2.txt
Vulkan :: Discarding "llvmpipe (LLVM 16.0.6, 256 bits)", because:
   - Not a GPU
libva info: VA-API version 1.19.0
libva info: User environment variable requested driver 'nvidia'
libva info: Trying to open /usr/lib64/dri/nvidia_drv_video.so
libva info: Found init function __vaDriverInit_1_0
libva info: va_openDriver() returns 0
VA-API :: Initialized device: renderD128
[ass] libass API version: 0x1701000
[ass] libass source: tarball: 0.17.1
[ass] Shaper: FriBidi 1.0.13 (SIMPLE) HarfBuzz-ng 8.0.1 (COMPLEX)
[ass] Using font provider fontconfig

I redirected output to a TXT file, but I canceled till it finished, cause repeat constantly sentences. QMPlay2.txt

[zaps166]

but it just crashes with that video

Probably fixed...

I'll push working OpenGL + VAAPI with this driver to master, but Vulkan still showing wrong colors.

[RafaelLinux]

zaps166 have reason. I downloaded that YouTube video and, depending of frame, color showed could be green or even blue. Image seems to have colours inverted.

[zaps166]

@RafaelLinux Ok, I just pushed to QMPlay2's master working OpenGL with this driver. Now we'll have to check Vulkan :smile:

[RafaelLinux]

I'm sorry, I forgot to say all my screenshots were took using Vulkan renderer.

[elFarto]

It looks like the driver is working fine here, and it's the Vulkan renderer of QMPlay2 that's causing the issue here.

[zaps166]

I'm sorry, I forgot to say all my screenshots were took using Vulkan renderer.

I know :sweat_smile:

It looks like the driver is working fine here, and it's the Vulkan renderer of QMPlay2 that's causing the issue here.

OpenGL crash was a QMPlay2 bug, but Vulkan is a different thing. On small videos (e.g. NV12 720p) luminance and chrominance are visible. On larger videos (e.g. NV12 1080p), only chrominance is visible (chrominance is 2x smaller than luminance on NV12). On large videos (e.g. NV12 2160p) nothing is visible. When I modify nvidia-vaapi-driver, it's working:

diff --git a/src/direct/nv-driver.c b/src/direct/nv-driver.c
index ad6c267..5ac65aa 100644
--- a/src/direct/nv-driver.c
+++ b/src/direct/nv-driver.c
@@ -355,7 +355,7 @@ bool alloc_memory(NVDriverContext *context, uint32_t size, int *fd) {
                  NVOS32_ALLOC_FLAGS_MAP_NOT_REQUIRED |
                  NVOS32_ALLOC_FLAGS_PERSISTENT_VIDMEM,

-        .attr = //pageSizeAttr |
+        .attr = DRF_DEF(OS32, _ATTR, _PAGE_SIZE, _BIG) |
                 DRF_DEF(OS32, _ATTR, _DEPTH, _UNKNOWN) |
                 DRF_DEF(OS32, _ATTR, _FORMAT, _BLOCK_LINEAR) |
                 DRF_DEF(OS32, _ATTR, _PHYSICALITY, _CONTIGUOUS),

@elFarto Could you look at this?

Btw. Is it possible to enable NVD_BACKEND=direct by default if nvidia-drm.modeset=1?

[elFarto]

Interesting that Vulkan doesn't like reading from the smaller page size (I think 4KiB). I don't see any reason why we can't bump that to 'big' pages (64KiB). I've pushed in a change for that. However I can't test it with QMPlay2's Vulkan backend as the build of QMPlay2 in Fedora doesn't appear to have Vulkan enabled.

I'm really hesitant to make the direct backend the default, as it's going to be a complete pain to maintain long term (NVIDIA have already made some changes that have broken us). With that said, NVIDIA still haven't fixed the EGL backend, even though they say the fix would be in the next release (which was like 3 releases ago), so I might have to re-evaluate that at some point

[zaps166]

I don't see any reason why we can't bump that to 'big' pages (64KiB).

Thanks!

the build of QMPlay2 in Fedora doesn't appear to have Vulkan enabled.

That's strange :astonished: You can try the AppImage. It doesn't contain recent fixes, but Vulkan + this driver should work now.

[zaps166]

It's working now, but I can notice stuttering/flickering (e.g. on 3840x2160 yuv420p10le VP9 video) on both OpenGL and Vulkan:

https://github.com/elFarto/nvidia-vaapi-driver/assets/6239090/5f831d44-ebcc-42e6-9156-a9e951f36ab5

[elFarto]

I assume that video is the HDR Costa Rica one on Youtube? I've grabbed that file, but I'm having a different issue playing it back, some sort of CUDA error. I'll take a look into it when I get a chance.

[zaps166]

Yes, it happens to me with HDR version of this video on VP9 codec, it's 10bit.