search

mpv-player / mpv

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

Random dropped frames but `stats.lua` doesn't pick it up #14245

Closed Obegg closed 4 weeks ago

Obegg commented 1 month ago

mpv Information

mpv v0.38.0-353-g021c5ded Copyright © 2000-2024 mpv/MPlayer/mplayer2 projects
 built on May 26 2024 15:03:59
libplacebo version: v7.349.0 (v6.338.0-133-g9e1257c-dirty)
FFmpeg version: N-115391-g63697d335
FFmpeg library versions:
   libavutil       59.20.100
   libavcodec      61.5.104
   libavformat     61.3.104
   libswscale      8.2.100
   libavfilter     10.2.102
   libswresample   5.2.100

Other Information

Reproduction Steps

mpv --no-config t.m2ts --fs --video-sync=display-resample --log-file=t.txt --vo=gpu-next --profile=high-quality --hwdec=yes --gpu-debug

Expected Behavior

No random visual frame drops, but if a frame were to drop - correctly pick it up on stats.lua and on log file.

Actual Behavior

Random visual frame drops, but stats.lua doesn't pick it up (dropped frames show 0, same with mistimed and delayed) and log file doesn't pick it up. I checked the logs and no error appears other than [vo/gpu-next/libplacebo] (Re)creating 2048x1768x0 texture with format r8: unknown.

Log File

t.txt - Using OSD to monitor dropped frames t2.txt - Not using OSD at all (still drops frames)

Sample Files

No response

I carefully read all instruction and confirm that I did the following:

Obegg commented 1 month ago

I think the problem was because I installed mpv on C:\Program Files\mpv, now it's on desktop and having no issues so far, will re-open this issue if I have the same issue.

llyyr commented 1 month ago

I think the problem was because I installed mpv on C:\Program Files\mpv, now it's on desktop and having no issues so far, will re-open this issue if I have the same issue.

Why would the install location matter?

Obegg commented 1 month ago

My guess is as good as yours. I think it might be folder permission thing, because it's on `Program Files" it needs more permissions... It also solved the yt-dlp issue I was having where some videos just wouldn't play and yt-dlp would cause high CPU usage until manually closed.

Obegg commented 1 month ago

I reopen this issue because apparently I did not fix it, I run some video tests of 23.976fps content and still encounter random frame drops which won't show up on stats.lua, what can be causing frames to drop and not report it on stats.lua?

Andarwinux commented 1 month ago

vd-queue-enable=yes vd-queue-max-samples=2

Obegg commented 1 month ago

I played around with many settings (unrelated to mpv) and currently (until I notice it again) it has been fixed, haven't tried the commands mentioned above this reply and at the same time I'm also not sure what fixed it (because I changed many settings - in BIOS, in NVIDIA Control Panel, Power Plans and more...) This is super random, even though I have a video file which is my testing video (23.976fps, motion test) sometimes it appear fixed and sometimes not fixed, which is why you can see me close/reopen the issue multiple times (because each time I get convinced that the issue has been fixed/not fixed) So to recap - currently - issue fixed for reasons unknown, closing (until issue returns).

Obegg commented 1 month ago

Reopening this issue since I still experience this issue (even with the commands suggested above)

Obegg commented 1 month ago

Even a fresh install of Win10 is not able to fix that issue.

Edition Windows 10 IoT Enterprise LTSC
Version 21H2
Installed on    ‎03/‎06/‎2024
OS build    19044.4412

Frames are being dropped and stats.lua doesn't catch that.

Andarwinux commented 1 month ago

I suspect this is a hardware or firmware issue.

Obegg commented 1 month ago

Before I assume it's hardware or firmware - I suspect it's the files, could anyone kindly provide me with a good video file to test stuttering on 23.976fps content? I already have a test file but I would like something else

Jules-A commented 1 month ago

Umm... You didn't actually mention if software decoding fixed it or not?

For the last month or so I've been experiencing a bug where if I alt-tab away while anything is using a decent amount of IO, MPV will freeze for 15-30secs and claim that shader compilation took that long, when it returns it will say around 150 dropped frames but it should be way higher. Have you monitored your disk usage while MPV is playing? Have you tried setting a larger cache?

Obegg commented 1 month ago

software decoding fixed it or not?

I have tried hwdec=no and hwdec=yes, no difference between them, same issue.

For the last month or so I've been experiencing a bug where if I alt-tab away while anything is using a decent amount of IO, MPV will freeze for 15-30secs and claim that shader compilation took that long, when it returns it will say around 150 dropped frames but it should be way higher. Have you monitored your disk usage while MPV is playing? Have you tried setting a larger cache?

Interesting... but I don't think we have the same issue. I use Samsung 980 PRO 1TB, without any programs running in the background. Buuut, I will say this - while my cache settings is demuxer-max-bytes=18GB (I have 32GB of RAM) the file itself I'm testing with is only getting 1sec of read ahead cache (while other files properly reading 18GB), this could be related to the issue, but not sure, that's also why I ask if someone can kindly provide my with a "proper" test video for stuttering (23.976fps) where I can properly test it.

llyyr commented 1 month ago

Before I assume it's hardware or firmware - I suspect it's the files, could anyone kindly provide me with a good video file to test stuttering on 23.976fps content? I already have a test file but I would like something else

https://github.com/mpv-player/random-stuff/tree/master/vsync

Obegg commented 1 month ago

Before I assume it's hardware or firmware - I suspect it's the files, could anyone kindly provide me with a good video file to test stuttering on 23.976fps content? I already have a test file but I would like something else

https://github.com/mpv-player/random-stuff/tree/master/vsync

Thank you.

mpv --no-config --fs --video-sync=display-resample --vo=gpu-next --profile=high-quality --hwdec=yes 23.976.mkv

Same issue. This file has no audio and the cache is only reading 1second ahead, and I still experience dropped frames without stats.lua catching them, so I think I need another file, this time with audio and a file that supports reading more than 1second ahead of cache, I really don't want to believe my hardware is failing (and even if it is failing I would have expected stats.lua to at least accurately catch dropped frames)

kasper93 commented 1 month ago

Does gpu-api=vulkan works better?

Obegg commented 1 month ago

Does gpu-api=vulkan works better?

Tested the following command 4 times (video length is 5 minutes so it's the equivelent of 20 minutes of testing):

mpv --no-config --fs --video-sync=display-resample --vo=gpu-next --profile=high-quality --hwdec=yes --gpu-api=vulkan 23.976.mkv

It does appear that gpu-api=vulkan fixes the issue (no frame drops).

-

Tested the following command 3 times (video length is 5 minutes so it's the equivelent of 15 minutes of testing):

mpv --no-config --fs --video-sync=display-resample --vo=gpu-next --profile=high-quality --hwdec=yes --gpu-api=d3d11 23.976.mkv

It does appear that gpu-api=d3d11 causes the issue (frame drops)

Something I noticed with d3d11 is that VSync Jitter is 0.0001 while winvk VSync Jitter is 0.3832, could it be related to the issue?

But winvk has issues such as https://github.com/mpv-player/mpv/issues/10716 (I have the same issue), so I'm not sure what I should do. Should I use a profile that will switch to d3d11 when video is 60fps?

Also (a while back) I noticed a bug with winvk that when I open HDR video the HDR colors (black and grey) are not the same when using d3d11, while winvk does auto toggle HDR on the monitor (unlike d3d11), it appears colors are not the same when manually toggeling HDR on Windows Settings and using d3d11 (I will test this specific off-topic issue later on and if needed - will open an issue).

kasper93 commented 1 month ago

Did it start recently? Could you try some older builds to see where the issue started?

There is something wrong with a/v sync code when the estimated vsync value is used and is changing. The bug is mostly hidden, if the estimated value is not used. It would be good if you were able to pinpoint regression range.

Could you check also this build https://github.com/mpv-player/mpv/pull/14286 ? This has nasty way of accumulating error unfortunately, even though one would think otherwise, the values are not that useful. But this shouldn't cause a problem, the underlying algorithm should be resilient to any vsync values and resync if needed. Else we are just hiding bugs.

Either way, I have more changes in this area that I need to finish, but this is tricky to debug and validate.

the-database commented 1 month ago

I have been running into the same exact issue recently (visual frame drops but no dropped frames reported by mpv), just in the past few weeks or so, having changed nothing about mpv in several months. I've been using gpu-api=vulkan the whole time, but tested d3d11 only after starting to see this issue, but I had issues with both settings.

I just tried using DDU to uninstall my NVIDIA driver, and then installed an older NVIDIA driver version, 551.86. And now I am not seeing any issues at all so far, but as Obegg stated above it's hard to tell if the issue is truly fixed until testing for a while. After using it more I'll report back whether the issue seems resolved or if it happens again.

kasper93 commented 1 month ago

There are a lot of variables at play here. The issue itself is not easy to reproduce, not always obvious to notice. We have to be systematic about it, else we will not get anywhere.

What we need

  1. Narrow down mpv version when the regression started. Or even check if it is regression in the first place.
  2. Gather information about the issue.
    • @Obegg says it is not reproducible with Vulkan
    • @the-database says Vulkan is also affected
    • This makes me think we are not looking at the exactly the same issue. Although it is hard to say, because it may be generic A/V issue that is exposed by different presentation timings.

Currently I'm not sure where to look for. I myself don't see the issue. Only dropped frames I get is when it indeed fails to render in time due to some other factors, but in normal playback I have not notice a problem. We need your help to narrow down the issue.

EDIT:

I know 3 remaining a/v sync issues, but I would not attribute frame drops to it as described here in this issue. Maybe I'm wrong here.

the-database commented 1 month ago

I would add that in one of my tests where it happened with vulkan, I was watching a 20 minute video and had around 15 minutes of perfectly smooth playback. Then it started happening at around the 15 minute mark of the video, and then once it started happening it would happen consistently on that video and other vidoes as well, and restarting mpv wouldn't help - the issue would continue to happen immediately once it started happening. I am curious if Obegg is able to reproduce the issue on vulkan after additional testing with longer length videos.

Obegg commented 1 month ago

@kasper93

Did it start recently? Could you try some older builds to see where the issue started?

I actually have no idea, and I think I know why I don't know - the content I watch doesn't have much panning shots where I would notice stuttering, which is mostly anime which is like their mouth is the only part the moves and not the rest of the frame.

Tested mpv-x86_64-v3-20240505-git-b086a40.7z from here: https://github.com/zhongfly/mpv-winbuild/releases/tag/2024-05-05-b086a40 Tested the same command as before:

mpv --no-config --fs --video-sync=display-resample --vo=gpu-next --profile=high-quality --hwdec=yes --gpu-api=d3d11 23.976.mkv

Same issue, noticed it after a short while like a minute or two, wasn't needed to run for 15 minutes.

There is something wrong with a/v sync code when the estimated vsync value is used and is changing. The bug is mostly hidden, if the estimated value is not used. It would be good if you were able to pinpoint regression range.

Is there anything I can test in order to help with that?

Could you check also this build https://github.com/mpv-player/mpv/pull/14286 ? This has nasty way of accumulating error unfortunately, even though one would think otherwise, the values are not that useful. But this shouldn't cause a problem, the underlying algorithm should be resilient to any vsync values and resync if needed. Else we are just hiding bugs.

Sure, Testing it (mpv-x86_64-w64-mingw32) right now. mpv-git-2024-06-03-292584f-x86_64: Tested the following command 3 times (video length is 5 minutes so it's the equivelent of 15 minutes of testing):

mpv --no-config --fs --video-sync=display-resample --vo=gpu-next --profile=high-quality --hwdec=yes --gpu-api=d3d11 23.976.mkv

It appears it fixes the issue. (Uh? Do I need to do more testing? I find it hard to believe it was fixed because I tried to so many things to try and mitigate that issue and none worked except apperently this PR) By the way, VSync Jitter is 0.0004

Off-topic but there's this error (which I've seen a long time ago): [vo/gpu-next/libplacebo] libplacebo compiled without LittleCMS 2 support! Is this error ever going to get fixed? I remember seeing it a while ago when I was testing some PRs, at the time it was spamming the console, this time it doesn't spam the console but it still exists.

Either way, I have more changes in this area that I need to finish, but this is tricky to debug and validate.

Great to know, thank you for sharing.

@the-database

I've been using gpu-api=vulkan the whole time, but tested d3d11 only after starting to see this issue, but I had issues with both settings.

Wait, are we talking about the same issue? I'm talking about dropped frames which are not reported to stats.lua, effectivily rendering stats.lua useless and can only rely on your eyes to tell if frames have been dropped or not (which is quite hard, need a test file and need to stare at the screen for long durations)

NVIDIA GeForce RTX 4090, 555.85

If you are experiencing the same issue with this beast of a GPU then I would assume it's not a hardware problem on my end and I can relax and breate, thank you for sharing.

On the same note about driver versions: Before the fresh install of Windows 10 I did use DDU to uninstall the NVIDIA drivers and I tried the 3 most recent driver versions which are 555.85, 552.XX (can't remember the exact number) and 551.XX (can't remember the exact number), same issue on all of them.

I need both of you to understand how I test it, I download this file https://github.com/mpv-player/random-stuff/blob/master/vsync/23.976.mkv and test with the following command:

mpv --no-config --fs --video-sync=display-resample --vo=gpu-next --profile=high-quality --hwdec=yes --gpu-api=d3d11 23.976.mkv

I open the stats.lua by Shift+I and then open the console to check for errors on both the stats.lua and on console, and I actually stare at the TV for 5 minutes straight (a few times to make sure).

kasper93 commented 1 month ago

Is this error ever going to get fixed? I remember seeing it a while ago when I was testing some PRs, at the time it was spamming the console, this time it doesn't spam the console but it still exists.

MSVC build has lcms2 included, currently it is not available, because of one external repository provider is upgrading their gitlab instance, should be back tomorrow.

EDIT:

I merged d3d11 change, it would be part of my other changes anyway and this way we can get some baseline testing anyway.

Obegg commented 4 weeks ago

@kasper93 Thank you! I believe the issue has been fixed. I'm not sure if I should close this issue from a couple of reasons:

  1. So far I did close this issue whenever I thought that this issue has been fixed, and reopening when I notice it again.
  2. @the-database says he have the same issue, just in vulkan.

So should I close this issue?

the-database commented 4 weeks ago

Wait, are we talking about the same issue? I'm talking about dropped frames which are not reported to stats.lua, effectivily rendering stats.lua useless and can only rely on your eyes to tell if frames have been dropped or not (which is quite hard, need a test file and need to stare at the screen for long durations)

I think we're talking about two different issues. Your issue was unreported dropped frames while using d3d11, which looks like it has been fixed in mpv. My issue is unreported dropped frames while using vulkan. I've done some more testing and here is what I found:

Based on the above, I think unreported dropped frames on vulkan is not an mpv bug, but an NVIDIA driver bug, so I believe this issue can be closed.

Obegg commented 4 weeks ago

Thank you for sharing. I will close this issue for now (I will reopen if I notice dropped frames again).