Mpv renders video at 2x container's frame rate

[anonmonogatari]

I don't know if "render" is the correct term for this problem but mpv produces 50FPS while watching 24FPS video also produces 60FPS while watching 30FPS video. It also uses graphic processor way more than quicktime. I also added iStat Menus's frame per second info screen at the Sample files section.

mpv version and platform

mpv 0.25.0 (C) 2000-2017 mpv/MPlayer/mplayer2 projects OS X El Capitan 10.11.6 (15G1510)

Reproduction steps

Open any video with mpv.

Expected behavior

Mpv renders at video container's fps.

Actual behavior

Mpv renders video at ~50FPS. (Nearly 2x. I say 2x because it also renders 30FPS video at 60FPS.)

Log file

http://sprunge.us/jJWd

Sample files

On the right quick time plays same video at real fps and on the left mpv plays video at 50FPS.

[Cpuroast]

Are you specifying any custom config in mpv.conf? Like do you happen to have "interpolation=yes"

https://mpv.io/manual/stable/#options-interpolation

[anonmonogatari]

Config

http://sprunge.us/fcGF

[Cpuroast]

Actually just tested on the same HD4000 video card using 10.12.5 and the same mpv 0.25 version with zero user-config and yes iStat Menus reports double the frame rate.

I think it's completely intended behaviour, either it's mpv or macOS' window manager is doing it.

I'm not registering as much GPU load, but that's because I only have the integrated 1680x1050 screen where as you have at least have an external 2560x1440 screen and the internal screen which is obviously more work for the older HD4000 GPU.

[Cpuroast]

Just so you know, you can drop these 5 lines:

vo=opengl -> Already the default https://mpv.io/manual/stable/#video-output-drivers-vo

framedrop=vo -> Already the default https://mpv.io/manual/stable/#options-framedrop

softvol=yes -> Deprecated option, always enabled https://mpv.io/manual/stable/#options-softvol

audio-pitch-correction=yes -> On by default https://mpv.io/manual/stable/#options-audio-pitch-correction

ytdl=yes -> On by default https://mpv.io/manual/stable/#options-no-ytdl

also, you should change softvol-max to volume-max, softvol-max is a deprecated alias and shouldn't be used. https://mpv.io/manual/stable/#options-softvol-max

also, hwdec=videotoolbox-copy will be less efficient than hwdec=videotoolbox https://mpv.io/manual/stable/#options-hwdec

[Cpuroast]

Also tried with a GT650M, same double framerate result with no user config.

[anonmonogatari]

Well I don't think it's the intended behaviour. Older mpv version does not behave same.

https://laboratory.stolendata.net/~djinn/mpv_osx/

I downloaded version 0.21 from here and it produces 25FPS. Also, other players that uses libmpv such as IINA (btw this build based on mpv 0.25) doesn't have this problem.

Thx for the config advice btw.

[Akemi]

I downloaded version 0.21 from here and it produces 25FPS.

there is quite a big gap between 0.21 and 0.25. it would be more helpful if you could tell us with what release it started.

[ghost]

@anonmonogatari does the GPU use go down with --video-sync=display-resample, stay the same, or does it get higher?

[Akemi]

i have a feeling the culprit is the early flush. does --opengl-early-flush=no fix it?

[anonmonogatari]

@wm4 --video-sync=display-resample makes mpv produce display's refresh rate which is 60 in my case (containers fps does not matter).

@Akemi --opengl-early-flush=no fixes the problem.

[Cpuroast]

Personally, I'd use:

video-sync=display-resample interpolation=yes

This would turn on interpolation and would make the video playback smoother, it would also actually make your "tscale=catmull_rom" directive do something as tscale only matters when using interpolation. https://mpv.io/manual/stable/#options-tscale

[anonmonogatari]

@Cpuroast video-sync=display-resample interpolation=yes

Is not always a viable option especially if you're on battery and have a hidpi screen.

[Akemi]

k, then it's loosely related to #3739. don't expect a fix for this any time soon, though i think the workaround should be sufficient enough for now.

[pcordes]

EDIT: nvm, vf-add=vavpp=interlaced-only=no + deinterlace=no changed. With --no-config (or without those config lines), everything's fine. With them, deinterlacing is active even before I hit d, causing frame-doubling. I get a solid blue video output window after hitting d twice.

I'm just going to have to figure out a different way to be able to enable deinterlacing when I hit d even for videos that incorrectly flag themselves as progressive.

Previous comment left below in case it helps anyone else who thinks they have this issue.

---

there is quite a big gap between 0.21 and 0.25. it would be more helpful if you could tell us with what release it started.

@Akemi: I started seeing this on Arch Linux when going from mpv 1:0.26.0-3 to 1:0.27.0-5. vo=opengl, hwdec=vaapi (Intel Skylake GT2 integrated graphics, i7-6700k). So Arch Linux's build of 0.26 on Linux / opengl didn't have this bug.

This bug introduces frame dropping when upscaling from 1280x720 to 1920x1080 with scale=ewa_lanczossharp / cscale=ewa_lanczossharp / profile=opengl-hq, for source FPS of 29.97. OSD shows FPS as 59.94 when I hit n, with this keybind in input.txt (i.e. for ${estimated-vf-fps:}):

     n show_text "${width}x${height}${?video-frame-info/interlaced==yes:i} ${estimated-vf-fps:} V ${video-bitrate:na} A ${audio-bitrate:na} ${video-frame-info/picture-type} (${=time-pos})"

It also introduces frame dropping with 1920x1080 video when I zoom (so the luma samples need scaling, not just chroma). And it sucks for playing 50fps or 60fps video.

My OpenGL setup is the usual X11 Xorg server with Mesa 17.3, running KDE with compositing disabled for fullscreen windows. (I forget, I may have disabled compositing all the time).

---

BTW, when single-stepping one frame at a time, the duplicated frames aren't quite identical. Text and other sharp lines has noticeable jitter even with deband=no / dither=no.

---

This still happens even with vo=vaapi, but not vo=x11. No frame-rate doubling with vo=x11, but obviously that's not usable. (Update: because the frame-doubling was from deinterlacing with vavpp, which also explains the jitter.)

[Akemi]

fixed via c5e4538bc4b63f02bf89f62aa25a37b9eb0c0316.