Mpv: MPV freezes on 'setting up fonts'

[Daktyl198]

MPV Version: 2016-2-29 x86_64 from mpv.srsfckn.biz
Windows 10 x86_64
Ytdl Version: latest available on 3-27 (though this doesn't matter as much)

Config file:

vo=opengl-hq:scale=ewa_lanczossharp:deband:backend=dxinterop
ytdl-format=bestvideo+bestaudio/best
hwdec=dxva2-copy

[pseudo-gui]
idle=yes

I've tried removing each option in my config file one by one but none of them help.

Description:
When opening MPV in any way (directly, double-clicking a local file, etc), for a few seconds after the window opens, MPV merely displays a white screen and appears frozen (ignores window commands like minimize/close). When viewing a youtube video from the command line like in the log I've attached, Youtube-dl is able to parse the video to the point where it knows the title and even puts it in MPV's titlebar before MPV freezes.

The time spent in this state can vary from <1 second to over 6 seconds. I've given the log file a look, but as it doesn't have timestamps I can't put my finger on what could possibly be the cause.

mpv-log.txt

[ghost]

This adds an external audio track, which means synchronous network access (do to how external tracks are handled), so it's conceivable that it just freezes on network.

[Daktyl198]

@wm4 I did a new test and found that it freezes right around "setting up fonts". I do actually have a large amount of fonts installed for a side-job that I do, so it would make sense. Any way I can get MPV to skip this step or something?

[Warblefly]

I've seen this on Windows 10, built from Git source, in the last few days also. No changes to Windows fonts made at all. But if it helps I'll trace where the program is going, just to see what the problem is.

In earlier days, when starting mpv for the first time since fonts were changed, this step _did_ pause the player's start-up, often for many seconds; but beyond the first run, it would start straight away. I imagine that's because fontconfig has made a cache of all the system fonts.

The pause is intermittent. That much, I've seen so far this evening.

[qyot27]

The white screen appearing (lagging) for several seconds before playback is caused by libass' DirectWrite support caching the fonts at startup. Unless there is a way to skip over caching the system fonts, users with large* numbers of fonts are probably better off using a fontconfig-enabled build that simply doesn't scan the Windows fonts directory and therefore only uses the default subfont and the fonts attached to the media file being played (or putting up with fontconfig caching all the fonts the first time).

*Prodigiously large; I've got somewhere around 2000 fonts installed, last I remember. I also seem to remember some seeking lag when using a DirectWrite!libass that isn't there with fontconfig!libass.

[Daktyl198]

Thanks for clarifying qyot27. I've got probably around 1500 fonts installed.

[ghost]

(This is a libass issue, btw.)

[akanosora]

This seems also cause the initialization of seeking freeze for a few seconds if using OSD is enabled. I wonder if there is any way to circumvent this?

[Akemi]

stale and upstream.