Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mvp can't smoothly play files when refresh rate is set high #5929

Closed
bahbarnett opened this issue Jun 15, 2018 · 3 comments
Closed

mvp can't smoothly play files when refresh rate is set high #5929

bahbarnett opened this issue Jun 15, 2018 · 3 comments

Comments

@bahbarnett
Copy link

Running Debian Stretch, with multimedia packages...

Relevant mpv -v:

[cplayer] mpv 0.27.2 (C) 2000-2017 mpv/MPlayer/mplayer2 projects
[cplayer] built on UNKNOWN
[cplayer] ffmpeg library versions:
[cplayer] libavutil 55.58.100 (runtime 55.78.100)
[cplayer] libavcodec 57.89.100 (runtime 57.107.100)
[cplayer] libavformat 57.71.100 (runtime 57.83.100)
[cplayer] libswscale 4.6.100 (runtime 4.8.100)
[cplayer] libavfilter 6.82.100 (runtime 6.107.100)
[cplayer] libswresample 2.7.100 (runtime 2.9.100)
[cplayer] ffmpeg version: 3.4.2
[cplayer]

Last week, I started to watch an old series "The Larry Sanders Show" (don't judge :P ).

Anyhow, it was jumpy and seemed to have issues keeping up. I have a reasonably beefy box:

model name : Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz

Reasonable enough graphics card:

06:00.0 VGA compatible controller: NVIDIA Corporation GP108 (rev a1)

Am using NVidia's drivers:

NVIDIA-Linux-x86_64-387.22.run

And have zero issues playing any 4k / 10 bit content I come across. I knew it wasn't a resource issue -- and immediately assumed it was just some weird bug with the encode.

So -- I procured a different version. Original was 240p, I then found 720p HBO upscaled mkv rips.. so all in all at least that part of debugging worked out well.

Yet, whether with 240p or 720p rips, the problem persisted.

After a lot of monkeying with the config file, and removal of many options -- everything seemed stable... and then kick in again. Very annoying to debug, until I finally noticed (and recalled) something.

xrandr and my refresh rate.

I use the lua xrandr script, but I tend to check bugs first prior to using something.. so I came across this bug report:

lvml/mpv-plugin-xrandr#1

And when I first installed mpv, it was on my desktop -- I used it for a while, before replacing mplayer on my media center. After all -- it's a PITA to try to debug in front of a TV, compared to on a desktop. So, I used the above changes for the xrandr.lua script + my desktop, and carried them over to my media center when I set things up there.

So... for some reason, X.org uses crazy CPU -- on the order of 70% of a single core, and playback becomes somewhat jumpy from time to time, even though mpv reports zero frames dropped/missed or sync issues.

For example, both of the above rips are 29.97 rips. Eliminating everything else, and using --no-config, if I set my refresh rate to 59.94? High x.org CPU usage, 70% at times on a single core, and random laggy/slow behaviour.

Yet, the same video? Refresh set to 29.97? Almost non-existent CPU usage by x.org -- and in both cases, mpv has very, very low CPU usage. 2%, something like that.

My problem is solved, as I simply reverted the change to xrandr.lua -- and it works beautifully now. Yet, I when looking at this bug, I was googling quite a bit, and I noticed that sometimes people with 4k TVs with edids that only have (for example) 60hz in them.. seemed to be complaining about weird behaviour too. I can't seem to find that bug now, my Google Fu is offline apparently.

Anyhow I wondered -- this is a fairly weird edge case. I searched the bugs a bit, and couldn't find anything similar... so I thought a report was warranted.

Also.. logs never seemed to help. Everything always reported fine, and mpv didn't ever report dropped frames. I suspect something in xorg is the issue here...

But, any logs wanted? Other info? Happy to provide.

Again, I'm OK now.. so, this is all informational...

Thanks btw guys, mpv has been awesome.

@bahbarnett
Copy link
Author

A couple of follow up comments.

If wondering 'eh?', to be clear -- with the revert, the xrandr.lua script now chooses the closest match. EG, a refresh rate of 29.97 for a 29.97 encode is preferred.

Before, it tried to find the highest, so it was choosing 59.94.

And, since I've been watching movies a lot.. and I have no higher multiple of 23.98, it's been sticking with that and I haven't noticed issues until now.

@mia-0
Copy link
Member

mia-0 commented Jul 7, 2018

I have never observed such behavior on my systems under similar circumstances (just running a different distro). However, your FFmpeg libraries differ from what mpv was built with. That’s Debian being retarded, and it can result in undefined behavior, which is especially likely when the version numbers are as far apart as yours. We have an explicit check for this case that is supposed to make mpv exit with an error, but Debian patches it out (which wouldn’t be a problem if their tooling actually ensured that the ABIs are compatible, which it clearly doesn’t).

Thus, I recommend that you try building mpv with mpv-build. This pulls FFmpeg and links it statically to the mpv executable, which allows you to test a consistent build without polluting your system.

Also, on the topic of idiotic vendor EDIDs: You can edit them with wxEDID and change the timing information. Surprisingly many displays that only have a 60 Hz mode are actually fine with e.g. 71.93 Hz. Some (notably LG and projectors with a spinning color wheel) duplicate frames though.

@Akemi
Copy link
Member

Akemi commented Sep 20, 2019

if this issue still persists, please open a new issue.

@Akemi Akemi closed this as completed Sep 20, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants