Mpv: Minor hang up during volume adjustment

[iZN1337]

mpv version and platform

mpv 0.29.0-107-gd6d6da4711 on Windows 10 Home x64 (1809)
(latest build off shinchiro's sourceforge)

Reproduction steps

• Opening any video file
• Adjust volume the very first time (increasing or decreasing)
• No lags/hang-ups after that

Expected behavior

Should normally adjust volume without any hang-ups.

Actual behavior

Video hang-ups for a few seconds or less, sometimes more than a second for some files whenever I adjust the volume after opening the file. It does not hang-ups after setting the volume the very first time. Even if I drag a new video file on the existing window, it won't hang up. It only happens when there is a new instance of mpv window.

Log file

https://gist.github.com/iZN1337/e04d083889dbfcebe056751787e3818b

Sample files

Happens with any video file for me at least.

--
I also found a similar closed issue #5406 where it happens to be the same issue as mine, but I'm here to provide any other info because I've already tried everything that is mentioned there, yet no luck. Default config, default input or with --no-config it's still the same behaviour. I also tried --ad-lavc-threads=0 and --volume=95.

[haasn]

Does --osd-level=0 help?

[iZN1337]

That helped. No hang up when I change the volume. @haasn but I'm assuming that's not really a solution since I cannot see the messages on the corner.

[haasn]

It's most likely font-related, probably due to slow font resolution. My guess is you have a lot of fonts on your system or something?

Besides the obvious fix (switching to a platform with a working fonts subsystem), the best work-around I can think of is to pre-lookup OSD fonts on startup.

[iZN1337]

Yep, I have around 4000+ fonts. I see why now it's a problem, but to add more: I'm running Windows on an NVMe SSD along with mpv on that drive too. So at least there are no HDD read speeds.

Is the work-around something I can do or it will have to wait for some update?

[zc62]

Realted: #2998

Not really sure if libass can be built with fontconfig or not on Windows. @shinchiro
A quick google search just tells me Windows does not support fontconfig well so probably no.
Without fontconfig, libass uses directwrite (related: https://github.com/libass/libass/issues/79)

Does XySubFilter require long font loading time? Probably should have a look at how the font is loaded in XySubFilter. (https://github.com/Cyberbeing/xy-VSFilter/blob/xy_sub_filter_rc4/src/dsutil/FontInstaller.cpp)

[shinchiro]

It can but with some hacks. Before xp support was removed, the mpv's libass always built with fontconfig.

[shinchiro]

Here's the mpv's build with libass-fontconfig-enabled. Try it out whether it solves your problem or not
mpv-x86_64-20190316-git-dd83b66-fontconfig.zip

[iZN1337]

I'm sorry I can't test this anymore since I have basically cleared out all of the downloaded fonts from the Windows folder and have switched to a font manager like FontBase. It was a huge pain for me to remove all of those fonts so I hope someone else can do it.

[weebo221]

I've tested it and works fine, no lags at all.

[Akemi]

see https://github.com/libass/libass/issues/334

[akanosora]

Here's the mpv's build with libass-fontconfig-enabled. Try it out whether it solves your problem or not
mpv-x86_64-20190316-git-dd83b66-fontconfig.zip

My mpv start-up has always been slow in Windows in the past (compared to Linux and OSX). I have 1400+ font files. This build solved the slow start-up issue.

[ghost]

I suspect that build either doesn't use the global font dir, or it uses the fontconfig cache from other mingw programs (probably the latter). I suspect it'll behave worse when font config has to rescan the fonts, e.g. when adding or removing a font file. Or fontconfig somehow fixed their slow mess.

[akanosora]

You are right that it uses the fontconfig cache. It did scan the fonts the first time I ran it and I saw the cache files were generated under AppData\Local\fontconfig\cache. (I deleted the cache and reran mpv to make sure it was generated by mpv) It did not take too long though, only a couple seconds (I'd say it's even faster than the bulid without fontconfig enabled.). What makes me happy is that once the font cache was created, mpv starts way faster with almost no latency whatsoever.

I can understand someone with a small font collection or has the need to frequently add or remove fonts might prefer the build without fontconfig. But for me, disabling fontconfig would make OSD unusable in Windows. Is that possible to make enabling/disabling fontconfig configurable through the config file?

[shinchiro]

fyi, I decided to build with fontconfig support in my future builds to avoid this kind of problem. Doesn't look like libass will fix it soon.

[avih]

Hmm.. tough choice, make it slow-ish every launch for people with thousands of fonts while fast all the time for the vast majority of users (direct write), or very slow for all users on first launch or whenever a font is installed/removed and fast for all users otherwise (fontconfig).

I know that for me it became much nicer when it started using direct write. The occasional very slow startup with fontconfig was a PITA for me.

Do we have some numbers to compare the slow-ness of the two methods?

Maybe fontconfig could be a runtime config of libass which mpv could support, so that most users will get the "fast all the time" solution, while those with extreme number of fonts could pick their poison?

EDIT:
At the log of the first post it shows a delay of ~850 ms and that's on a system with 4000 fonts. I expect that even people with many fonts will rarely reach 4000 installed fonts (do correct me if I'm wrong). OTOH, IIRC the fontconfig delay for me with maybe a dozen manually installed fonts was many seconds (I don't recall the numbers, 10s? 30s?), and it was very painful for me.

Also, I'd think that those with extreme number of fonts will add/remove fonts relatively frequently. Won't this make fontconfig very painful for them too?

EDIT2:
Maybe this lag with direct write could be made earlier when mpv starts rather than on first libass display (OSD/OSC/subs), either by explicitly asking libass to do its slow thing or by just rendering a dummy libass thing on startup? Would that be an acceptable solution?

[shinchiro]

or very slow for all users on first launch or whenever a font is installed/removed and fast for all users otherwise (fontconfig).

This doesn't true anymore since I'm patching the fontconfig. First launch is faster like using directwrite-libass. The only things I'm uncomfortable is bundling noto sans fonts inside each build

I compiled libass with fontconfig support today. You can test it if you want: https://sourceforge.net/projects/mpv-player-windows/files/64bit/mpv-x86_64-20200105-git-9eb3991.7z/download

[avih]

What's the libass patch? Maybe PR it?

EDIT: fontconfig patch (personlly I'd be uncomfortable with that)