search

mpv-player / mpv

🎥 Command line video player
https://mpv.io
Other
28.62k stars 2.92k forks source link

'gpu-api=vulkan' does not show any video for files with AV1 videocodec on Windows #7743

Closed Areteic closed 4 years ago

Areteic commented 4 years ago

Important Information

Provide following Information:

All of the black space (except cmd window) is actually mpv. OSC that you see is frozen and was not resized to match window dimensions

If you're not using git master or the latest release, update. Releases are listed here: https://github.com/mpv-player/mpv/releases

Reproduction steps

  1. Use mpv with build not older than mpv-x86_64-20200517-git-152b0e2
  2. In mpv.conf or through console set gpu-api=vulkan
  3. Play videofile with AV1 codec

Launching mpv with --no-config allows it to play video as normally since it defaults to d3d11 output.

Describe the reproduction steps as precise as possible. It's very likely that the bug you experience wasn't reproduced by the developer because the workflow differes from your own.

Expected behavior

mpv will play both video and audio with no problems

Actual behavior

mpv will resize window to match dimensions of video but fail to actually show any video output. Audio will play for a 2-3 seconds then pause for another 2-3 seconds. After that mpv window resizes trying to match video dimensions but it just gets bigger. After window has been resized audio will continue to play without any video output.

Log file

log.txt

Sample files

Basically any videofile with AV1 videocodec. For generating log I used youtube video: https://www.youtube.com/watch?v=ibXKKllz4xQ

haasn commented 4 years ago

Can you post another log with --gpu-debug enabled? The first error I see is VK_ERROR_DEVICE_LOST on vkQueueSubmit.

Areteic commented 4 years ago

Here is log with --gpu-debug log_gpu-debug.txt

aufkrawall commented 4 years ago

Windows event log shows Nvidia driver crash here.

haasn commented 4 years ago

Having a bit closer look at your logs, I can take away the following points:

It seems that the offending combination is us using timers on the transfer queue. This works fine for me on AMD during testing, and it doesn't trigger the validation layers for me either, and the spec says it's fine as long as timestampValidBits is non-zero - and we explicitly check that condition. It also surprises me because I remember that nvidia used to report 0 here in the past.

Maybe some nvidia driver revision introduced timer support on the transfer queue but it was never fully tested and now you're hitting this bug? Anyway, almost definitely not an mpv issue. As a work-around you could probably just disable async transfer for now.

Edit: Actually, I managed to hit a case in which the validation layers do trigger for me.

haasn commented 4 years ago

Seems the issue is that, while vkCmdWriteTimestamp is fine to run on transfer queues, vkCmdResetQueryPool is not. That's.. incredibly annoying. But fixable.

Areteic commented 4 years ago

Tried your suggestions and can confirm it behaves exactly as you described:

haasn commented 4 years ago

Anyway I pushed a fix to libplacebo for the time being, that simply disables timers on async transfer queues. But in theory on vulkan 1.2 I could support them again. I'll write the code for that when I'm less preoccupied