mpv-x86_64-20200105-git-9eb3991 on Windows 10 64bit
Use sub-font="Impact" or sub-ass-force-style="FontName=Impact" (or any other installed font) in mpv.conf, open video file with subtitles (external .srt or embedded .ass).
Subtitle font should be what is defined with the sub-font or sub-ass-force-style=FontName commands. This issue has only appeared with the mpv-x86_64-20200105-git-9eb3991 build. Going back to the previous build of mpv-x86_64-20191229-git-49cbc50 fixes it, so it's a newly introduced bug.
Subtitles are always the default font, Noto Sans, I believe.
Probably due to @shinchiro switching builds to fontconfig rather than an mpv code change: https://github.com/mpv-player/mpv/issues/6447#issuecomment-570849105
Looks like your log doesn't actually play long enough to show any subtitles. A log where you don't quit until a subtitle actually shows up might have more information. Though it'll probably just show an attempt to find Impact that fails and defaults to NotoSans instead.
You need to edit fonts.conf inside in the mpv folder.
In line 9, change <!-- <dir>WINDOWSFONTDIR</dir> --> to <dir>WINDOWSFONTDIR</dir>
This will make fontconfig find installed fonts in windows. By default, it only find fonts inside fonts folder in the build folder.
Looks like your log doesn't actually play long enough to show any subtitles. A log where you don't quit until a subtitle actually shows up might have more information. Though it'll probably just show an attempt to find Impact that fails and defaults to NotoSans instead.
Whoops, I do apologise, here's another log where subtitles actually show (which is probably not needed any more): output.txt
You need to edit
fonts.confinside in the mpv folder.
In line 9, change<!-- <dir>WINDOWSFONTDIR</dir> -->to<dir>WINDOWSFONTDIR</dir>This will make fontconfig find installed fonts in windows. By default, it only find fonts inside
fontsfolder in the build folder.
Uncommenting that line does indeed fix the problem. Thanks Shinchiro!
Should mpv find installed Windows fonts by default instead? Or is the way I have my mpv setup such an edge case that it isn't necessary? If the latter, then I guess I'll just have to remember to edit that line every update and we can consider this issue closed.
Thanks everyone for all the help.
Or just copy the impact fonts into the fonts inside the build folder and forget about it. No need to edit the line on every update. I'm assuming majority of user dont even bother to change the default noto fonts.
btw, the issue can be closed since its not related to mpv changes
@shinchiro Why not default to read system fonts? I believe the majority of the users care about using custom fonts in the system folder to render fancy ass subtitles. At least on a user forum I heard someone complaining about why ass subtitles fail to show the correct font after the recent update.
Because it's slow and the exact cause for the infamous vlc "scanning fonts" dialog?
It's slow for the first time, but fast afterwards. I think it's a bit easier for users to endure the only one time slowness, rather than to be confused about why system fonts just don't work, and get mad. Not too many people know that they should edit the fonts.conf.
Or put it in another way, this kind of issues will continue to occur, unless reading sys fonts is the default.
Not even sure if shinchiro's switch from directwrite to fontconfig in his Windows builds is a good move to be honest, since apparently only a couple issues popped up complaining about lag and/or framedrops when displaying the OSC/OSD for the first time.
I mean, how many people have +2000 fonts installed in their Windows\font dir nowadays?
There are. Fan-made ASS subs can use quite many different kinds of fonts, and a collection of many fan-made subs can result in a few thousand fonts. I personally have quite some fonts installed in the fonts dir (while not yet reaching the point that DW becomes slow).
Not too many people know that they should edit the fonts.conf.
Second this. People would intuitively expect that fonts installed into the system are ready to use. It's better to have this enabled by default, since that would work out of the box for most people, and the minorities who want to disable it would know what they're doing anyway.
I mean, how many people have +2000 fonts installed in their Windows\font dir nowadays?
Is that why it was switched to fontconfig? That seems strange, because if you make fontconfig use system font, it surely will be even slower. And fontconfig AFAIK rescans all fonts if a single font gets added or removed.
If libass is built with both, --sub-font-provider and --osd-font-provider can be used to select it, but DirectWrite will pick it by default, which will make it behave as previously, but would allow whatever people want something else to edit their config. (Question is, how many would know this and bother etc.)
If libass is built with both,
--sub-font-providerand--osd-font-providercan be used to select it, but DirectWrite will pick it by default, which will make it behave as previously, but would allow whatever people want something else to edit their config. (Question is, how many would know this and bother etc.)
Didnt know there's option to change font provider. I guess I'll just compile libass with fontconfig and directwrite support and call it a day
since shinchiro is going to compile both font providers now.
Most helpful comment
You need to edit
fonts.confinside in the mpv folder.In line 9, change
<!-- <dir>WINDOWSFONTDIR</dir> -->to<dir>WINDOWSFONTDIR</dir>This will make fontconfig find installed fonts in windows. By default, it only find fonts inside
fontsfolder in the build folder.