Search options (Page 1 of 2)

Seems to work, thanks!
I had no idea these profile conditions result in scores, always assumed they evaluate as boolean.

In case feature requests can be made: in the future it would be really neat to make the "Temporarily disable SVP" setting persistent, so when you reopen SVP again it's still active in case it was when you quit SVP.

Didn't notice that.
Well, does SVP still perform an analysis step? I suppose the actual motion interpolation might be a no-op, but it will still analyze frames? Just a guess.

It ships mpv as binary: https://github.com/lhc70000/iina/tree/master/libmpv/lib and I assume they don't compile with vapoursynth. When you compile yourself (with vapoursynth) (you can use homebrew to compile libmpv) it should work as you can use all mpv options. But someone better test this before you believe me, I'm just speculating.

Are you maybe using windows line endings because mpv apparently doesn't see this new line.

Random fact: you can all of the "script=" lines (the last one overwrites all previous lines anyway). Scripts are automatically loaded from this directory.

Ah, streams. Well, I think I might have a pretty good solution for you.
Get this script and put it into your mpv scripts folder: https://github.com/wm4/mpv-scripts/blob … ofiles.lua
Now you can create profiles that are applied based on lua expressions. Additionally, you can use mpv properties like normal variables.

E.g.:

[svp-crunchyroll]
profile-desc=cond:get('container_fps', 0) > 23 and get('container_fps', 0) < 23.9
fps=23.976
...

It's not a perfect solution. The profile expression is re-evaluated every time the used properties change and applied/activated when it evaluates to true. Therefore, when watching streams with variable fps it could activate the profile (e.g. when the fps suddenly drop below 23.9 but stay above 23 (in this case)).
Of course you can make your own, even more precise conditions.

Note: profiles do not get "unapplied". In case you want to "unapply" a profile you need an inverted version, e.g.:

[4K]
profile-desc=cond:get('width', -math.huge) >= 3840
vd-lavc-threads=32

[4K-inverted]
profile-desc=cond:get('width', -math.huge) < 3840
vd-lavc-threads=0

Well the difference just stems from Quicktime using hardware decoding by default while mpv doesn't (it's optional).
Also, just because you see a low CPU usage doesn't mean the general usage/energy consumption is low. In this case the major work is simply shifted to the GPU.

Add "hwdec=auto-copy" to your config to enable hardware decoding. Please note that this supports only a subset of video codecs.
Now you should be pretty similar to Quicktime.
If you want more quality (better upscaling etc.) you can also add:
vo=opengl
profile=opengl-hq
But this will also (drastically) increase the load on your GPU.

Well that's true but we are also talking about close to 4K resolutions here (thanks to "retina"), depending on the exact settings, and then it's getting difficult.

The cause of the problem is a damaged file (incorrectly tagged FPS/duration). Therefore, in my opinion, the only sane way to fix this is by fixing the damaged file: remux it with the correct FPS value. Remuxing takes like 2 seconds, it won't change the video or audio and fixes the problem mentioned here, for every player.
I don't think that configuring/changing behavior of your player is a good solution for fixing an error in a file that can be corrected so easily just by remuxing.

A incorrect FPS value in the container is actually so common that every decent video player simply ignores it and does playback without. E.g. many .wmv files have a tagged FPS value of 9999. mpv offers this container fps value as property for scripts etc.
mpv contains one more fps property: estimated fps. This is the real FPS value which is also correct for incorrectly tagged videos. There is one drawback: it is a measured value, averaging over the last n frames. Consequently, it is only correct after n subsequent samples (i.e. only after a few frames were rendered) and it might change during playback (e.g. variable frame rate videos). Therefore it is unsuitable for a script that calculates stuff on startup like SVP

I just noticed due to this thread: http://www.svp-team.com/forum/viewtopic.php?id=3680 that it's actually only 10.11 and up now due to a problem with a vapoursynth dependency (https://github.com/Homebrew/homebrew-co … img.rb#L18).

Considering it works for brucethemoose I'd say it's a bug.
Android is very fragmented (hardware as well as software) and I guess these ~2 developers can't test every device and version so I'd assume they appreciate bug reports.