Smooth motion like madvr?

[Soukyuu]

I have recently tried mpv again, just to compare it against mpc-hc with madvr output. The first thing that I noticed is that all the 23.976fps videos appeared less smooth on pans on my 60Hz monitor.

madVR has a feature called "smooth motion", where it converts the framerate on-the-fly, allowing to keep the smoothness of video playback. It would be really nice to have something like that in mpv in the future.

[ghost]

Maybe one day...

[mia-0]

Should be noted that this is just frame blending with variable blending factors which are calculated on each vsync interval.

[ghost]

Similar feature request: #566

[kevmitch]

This is related to the other wish-list item #552. In a perfect world, you would just get the display to output the correct refresh rate and only if that fails, resort to frame blending.

[pigoz]

@Soukyuu I implemented it in the smooth-motion branch. If you want you can test it and check whether the result is satisfactory (I'd love to hear your feedback especially if you used the same feature in MadVR). The algorithm should be equivalent to the MadVR one.

[Soukyuu]

Great news!

Might be a stupid question, but is smooth motion on all the time or is there a way to toggle it on and off to be able to compare it without having to install the non-sm build? There doesn't seem to be any log message about it in the console.

On my only linux PC (which is a weak AMD e-350 one), I'm seemingly getting the same stuttery camera pans so far, with no blur added. If someone would be so kind to provide a windows build, I'd be able to test more reliably, I guess.

[pigoz]

@Soukyuu there's the :smoothmotion sub-switch. i.e.: --vo=opengl-hq:smoothmotion

[Soukyuu]

@pigoz it's working, but I have a weird side effect: the image is shaking left-right for about two pixels all the time, even on still scenes, which makes it look even worse than without smooth motion.

I actually remembered I had another PC with linux (C2D+NV8600), so I tested there as well and same thing happens. This is on arch x64 with the radeon/nvidia drivers installed, respectively. Happens on all mkvs tested, for example Vivid-Asenshi's Akame ga Kill 23

[Argon-]

(I can confirm the stuttering using --vo=opengl-hq:smoothmotion on OSX)

[pigoz]

it doesn't seem to happen here :/

[pigoz]

I pushed a commit that may or may not fix it.

[Soukyuu]

Still happening here. Tried with both 8-bit and 10-bit h264.
I must say that since nVidia dropped support for older models again, I'm stuck on legacy drivers (340.65). Newest drivers otherwise.

[Nyx0uf]

Like @pigoz I don't have the problem on this mac (10.10) tried with : mpv ~/Downloads/ar.mkv --no-config --vo=opengl-hq:smoothmotion --display-fps=60

[Soukyuu]

I just saw #1338 and it seems that the "garbage pixels on the right" mentioned there are actually the first few pixels from the left side of the screen. Could that fix have something to do with the shaking?

This time tried with:

mpv ~/test.mkv --vo=opengl-hq:smoothmotion --no-config

[pigoz]

There should be no garbage pixels, is the correct commit checked out?

[Soukyuu]

I meant that your fix fixing that issue might have something to do with mine and @Argon- issue. No garbage pixels visible with the commit currently checked out.

[Argon-]

At the time I noticed it (yesterday, after your linear light commit) I didn't do any testing (not even --no-config) since I assumed the branch is still WIP. Unfortunately I won't be able to do this before ~tomorrow.
I'm using an external display btw.

[Argon-]

Doesn't happen when using commit adc236c, but I'm not sure if opengl-hq:smoothmotion is working there because I see no difference.
edit// the last one was a problem on my end. there is a difference.

[Soukyuu]

Same here, that commit works (but has garbage pixels at the bottom). So looks like I was right about the fix for the garbage fixing breaking it for me.

I can also see it's working, but compared to madvr it looks like it introduces more blur and still leaves some stutter where madvr does not.

Take akame ep 23, the third scene after the OP (horizontal pan in front of the gate:

• smooth motion off: there is a stutter about every second
• madvr smooth motion: blurred afterimages are about 5 pixels apart
• mpv smooth motion: only blurs every second stutter, afterimages are about 10 pixels apart

It kind of looks like madvr either interpolates more often, or has a different criteria to interpolate.

[pigoz]

Hm maybe mpv is missing the vsync in your case?

[Soukyuu]

I am not sure about that, because the latest commit didn't seem to have the issue. Maybe it was being masked by the shaking of the image?

I looked at nvidia-settings and "sync to VBlank" is enabled. The display is a regular 60Hz TFT

[Soukyuu]

I have just tried the latest commit, and the L/R stutter is gone.
I have also found out that enabling smooth motion causes both my 8600m GT and the Radeon 6130 to drop frames :(

I assume this is also the reason why with smooth motion enabled it appears more jerky than without it. Running with --vo=opengl:smoothmotion appears less jerky, but about the same number of frames is reported as dropped. Both GPUs were able to handle madvr's SM.

[pigoz]

keep in mind that the framedrop count is busted (it reports as drops stuff that is not a real drop)

edit: I just changed how the frame dropping code reports frame drops to avoid the wrong numbers.

[Soukyuu]

Oh, didn't know that. With the new revision, no frames are reported as dropped, but the jerkiness with SM enabled still appears to be higher for me as described above.

[Soukyuu]

I managed to compile a cygwin build on my windows 8.1 x64 machine and it runs a lot better on a 260GTX. It's definitely an improvement over SM disabled and it also seems to be less blurry than madvr, unless I'm seeing things.

There are a few jerks now and then though, which only happen randomly: replaying the scene, parts that didn't stutter might stutter and vice versa. If you need me to provide any information, just ask.

[pigoz]

Maybe on your particular configuration mpv is missing some vsyncs (as opposed to madvr we don't prerender frames). If this started being an issue in the latest commits, I can make the code a little smarter and draw as soon as possible (to avoid being late for the vsync), and then sleep until the vsync.

[Soukyuu]

I'm not sure if it started happening on latest commits, because I always attributed the jerking to the lack of smooth motion. It's happening on all 3 machines though and on different OSes, plus they're all fairly low end by today's standards, so maybe that's it.

Why is mpv not pre-rendering frames though? That could improve performance for lower end hardware.

[pigoz]

In the last commits I changed slightly the timing at which each frame is prerendered (before it was at early as possible, now it's at most 4ms before vsync but that could cause problems with bad hardware), so that's why I asked specifically.

From my understanding, MadVR also prerenders several frames in advance, but that would be very hard to do in a simple way within mpv.

[ghost]

Why is mpv not pre-rendering frames though?

I'm not confident that this would be possible in OpenGL without running into severe problems and overcomplications.

[Soukyuu]

I'm not sure if I'm not just getting hit by a performance penalty because of compiling and running mpv via cygwin. Are there native build instructions for windows? How are the binaries by @lachs0r compiled?

About buffering, good to know. My openGL knowledge is pretty basic, hence the question.

[kevmitch]

@Soukyuu There are three ways to get a native build:

• msys: fully native build on windows for windows. I haven't tested this myself
• mxe: build on linux to run on windows using released versions of dependencies
• mingw-w64-cmake: build on linux to run on windows using latest development versions (e.g. git head) for dependencies where available.

mingw-w64-cmake is what lachs0r uses for the windows builds. I however find mxe easier as it has fewer intermittent failures due to constantly changing dependencies. I haven't tried msys, although it sounds pretty straightforward.

[Soukyuu]

• msys: fails to see includes/ffmpeg even though packages are installed
• mxe: link doesn't work - 404
• mingw-w64-cmake: fails at building binutils because all warnings are treated as errors. Same after I added -Wno-error in it's Makefile, and I'm not seeing any -Werror flags anywhere.

[ghost]

The instructions for mxe and msys2 are now on the same page: https://github.com/mpv-player/mpv/blob/master/DOCS/compile-windows.md

[Soukyuu]

I'm giving up. mxe builds binutils fine, but fails to build bzip2 because

make[2]: x86_64-w64-mingw32.static-gcc: Command not found

That's on two separate PCs.

The pre-made mingw64-cmake env vmdk image fails at download/verify/extract openssl step

[Soukyuu]

That's what I meant by pre-made mingw64 image

edit: it could probably be faster if you just make a test smooth motion build if it works for you...

[mia-0]

Yesterday it worked. Seems like openssl.org fucked up and deleted the source archive.

[mia-0]

Let’s just wait until openssl.org stops being terrible at everything they do and gets the archive back up.

[Soukyuu]

I guess.
Any idea why waf is being blind about the include/lib paths even though I set the prefix as mentioned in the instructions?

[mia-0]

They’ve just now released a new version. It built successfully here so I’ve pushed the update to mingw-w64-cmake.

[Soukyuu]

Well, I don't know.

[24/272] Performing patch step for 'enca'
 FAILED
Applying: Lazy cross compile fix
error: patch failed: configure.ac:97
error: configure.ac: patch does not apply
error: patch failed: tools/Makefile.am:31
error: tools/Makefile.am: patch does not apply

[mia-0]

Does it work if you rm -rf packages/enca-prefix and retry?

[Soukyuu]

Yes. I'm stuck at ffmpeg step now with the same problem, and removing ffmpeg-prefix doesn't solve it.

I was able to get msys working though (was starting msys2.bat, not mingw64-shell.bat) and it turns out the performance is on par with the cygwin build. It also shows exactly the same behavior, so I think it's something about the code.

Another interesting thing is that enabling smooth motion pushes my CPU usage to 60% per core (AMD Phenom II X4 970@3,4GHz), while GPU usage does not increase, or rather, is really low.

• madvr: 16% CPU / 48% GPU
• madvr + sm 16% CPU / 51% GPU
• mpv opengl: 10% CPU / 2% GPU
• mpv opengl:smoothmotion: 60% CPU / 4%GPU

That's a really huge impact on CPU...

[ghost]

That seems pretty wrong. Maybe some active waiting or so.

[mia-0]

(The ffmpeg problem is fixed now, git pull and remove ffmpeg-prefix.)

[Soukyuu]

Well, fwiw, the impact on my linux machine (core2duo T7250@2GHz) is not that big, only about 10%

(I managed to finish compiling mpv in VM, but it crashes on start with a generic "stopped working" message even without any options specified)

[mia-0]

That would indicate the mpv repo isn’t updating properly.

Sigh.

[Soukyuu]

Well, from what I saw I had to modify packages/mpv.cmake and add a

GIT_TAG smooth-motion

to it under the GIT_REPOSITORY. Maybe that broke it?
Though the log says "HEAD is now at 75dbe8b vo_opengl: add smoothmotion frame blending", so it seems to be the smooth motion branch...

[mia-0]

Okay. The fix that went into master earlier isn’t in the smooth-motion branch
yet.

[pigoz]

Now this is in master with some changes. If the result doesn't look ok on your system, please open another ticket.