Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

xy-SubFilter finds non-attached regular font-variant, libass the attached bold variant #509

Open
MatiasMovie opened this issue May 12, 2021 · 21 comments

Comments

@MatiasMovie
Copy link

Players: mpv, mpc-be (with madvr)
File: https://mega.nz/file/D9JSQCSB#AsAPetej_kUJ5RA-7uyMyzBZeaZNTw6VMlRSPVKeuFs

Screenshots:
mpv (libass, probably 15.1)
image

XYsubfilter (https://github.com/pinterf/xy-VSFilter/releases)
image

XYsubfilter with libass [probably 15.1] (https://github.com/Masaiki/xy-VSFilter/releases/tag/xy_sub_filter_with_libass)
image

@TheOneric
Copy link
Member

The linked mkv-file only has the bold variant of TW Cen MT attached (TCB_.TTF), yet the subs try to use the Regular+Italic-variant. Here's the relevant excerpt:

[Script Info]
; Script generated by Aegisub master r8903+1 g1042226, line0
; http://www.aegisub.org/
ScriptType: v4.00+
WrapStyle: 0
PlayResX: 720
PlayResY: 480
ScaledBorderAndShadow: yes
YCbCr Matrix: TV.601

[V4+ Styles]
Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour, OutlineColour, BackColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY, Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, MarginV, Encoding
Style: Dialogi,Tw Cen MT,34,&H0000D0D0,&H0000FFFF,&H00000000,&H00000000,0,0,0,0,84.408,100,0,0,1,1.5,0,2,8,8,35,1

[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:00:07.96,0:00:14.43,Dialogi,,0,0,0,,{\i1}Niezliczone akty ludzkiego szaleństwa\Ni przemocy na niezliczonych polach bitew.{\i0}

And some properties of TCB_.TTF as displayed by fontforge:

Fontname:         TwCenMT-Bold
Family Name:      Tw Cen MT
Name for Humans:  TW Cen MT Bold
Weight:           Bold
Version:          1.02

Since the linked mkv doesn't bundle the version the subs actually try to sue, I suspect this is just a case of a borked mkv and a missing font varaint, but to be sure:

Please provide logs for mpc-be using normal xy-SubFilter, and additionally a log for mpv with libass would also be nice.
For mpv you can generate a log file by additionally specifying --log-file=mpv-log.txt when playing the file.
Also some more questions:

  • Are all of those screenshots taken on the exact same machine and OS-installation?
  • Are you using some font manager or on-demand font installer?

@TheOneric TheOneric changed the title other-looking subtitles xy-SubFilter finds non-attached regular font-variant, libass the attached bold variant May 12, 2021
@MatiasMovie
Copy link
Author

Please provide logs for mpc-be using normal xy-SubFilter

How to do it?

For mpv you can generate a log file by additionally specifying --log-file=mpv-log.txt when playing the file.

mpv-log.txt

Are all of those screenshots taken on the exact same machine and OS-installation?

Yes

Are you using some font manager or on-demand font installer?

No, but I have lot of fonts instaled

@astiob
Copy link
Member

astiob commented May 12, 2021

I think this may just be the DirectWrite font provider regression in 0.15.1? It’s odd that the two libass screenshots are different from each other though.

@astiob
Copy link
Member

astiob commented May 12, 2021

Please provide logs for mpc-be using normal xy-SubFilter

There is no such thing (the logs). Or is there?

@astiob
Copy link
Member

astiob commented May 12, 2021

Hang on, I got it:

Whenever libass needs a font, it searches through already-known fonts. If it finds a match, it uses that match. If not, it asks the system for more fonts.

In this case (with the new DirectWrite font provider, but equally well with the Core Text font provider on macOS), the already-known fonts are the fonts attached to the MKV, as system fonts have not been queried yet. There’s a family name match, so libass uses that font.

If we want to treat this as a regression (and longstanding macOS bug), then presumably we want to make it call match_fonts for every new name encountered. I actually had this thought, or something similar, a few weeks ago… I wonder what the context was.

@MatiasMovie
Copy link
Author

MatiasMovie commented May 12, 2021

I think this may just be the DirectWrite font provider regression in 0.15.1? It’s odd that the two libass screenshots are different from each other though.

idk, maybe something is with aspect ratio

Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 16:9
Original display aspect rat : 3:2

Please provide logs for mpc-be using normal xy-SubFilter

There is no such thing (the logs). Or is there?

Trying to generate something in mpc-hc but no result

@astiob
Copy link
Member

astiob commented May 12, 2021

I actually had this thought, or something similar, a few weeks ago… I wonder what the context was.

Ah yes, I remember! I was thinking that match_fonts("foo") can by accident return a font with a family name "bar" without returning all fonts that share family name "bar". (This can happen with the Core Text provider, but possibly not with the latest DirectWrite provider code.) Then a later instance of \fnbar will be locked into that one font match_fonts("foo") previously returned, even if it’s not the best face from the bar family.

@vxzms
Copy link

vxzms commented May 13, 2021

The problem maybe video’s DAR cause.
The original video size is 720*480, mkv flag display-dimensions is 873*480. mpv render subtitle by the flag; mpc-be’s VSFilter and XySubFilter_libass maybe don’t read the flag when render subtitle; XySubFilter will according to the flag if set More - Renderer layout options - Use Original Video Size. Then I check subtitle in Aegisub, it have ScaleX 84.408 in style and Aegisub render subtitle according to the flag, so it‘s display is similar to mpv (if b9f3468 or before 0.15.1).

In addition, libass is slightly different from VSFilter when I use this in Aegisub to render the subtitle, but I think it’s nothing to do with the issue.
https://slow.pics/c/330Uw80c is my comparison of libass (with b9f3468) and xy-VSFilter by Aegisub. TCB_.TTF is system font.

@MatiasMovie
Copy link
Author

MatiasMovie commented May 13, 2021

In addition, libass is slightly different from VSFilter when I use this in Aegisub to render the subtitle, but I think it’s nothing to do with the issue.

Similar in Kainote 0.9.8.1330
https://slow.pics/c/AMxLjl1Y

@astiob
Copy link
Member

astiob commented May 13, 2021

The problem maybe video’s DAR cause.

DAR can cause the stretchedness difference between mpv and XySubFilter_with_libass, but that’s not what this issue is about. The mpv screenshot is correct here, and the XySubFilter_with_libass one wrong. Seems like an issue in XySubFilter_with_libass. For comparison’s sake, similarly stretched images can be obtained from mpv by setting --sub-ass-vsfilter-aspect-compat=no or pressing V during playback.

(The XySubFilter screenshot is correctly stretched, too, but uses a different font.)

Either way, that’s not what this GitHub issue report is mainly about; it’s about using the wrong font. Unless that’s what OP actually meant to report?

@MatiasMovie
Copy link
Author

MatiasMovie commented May 13, 2021

Either way, that’s not what this GitHub issue report is mainly about; it’s about using the wrong font. Unless that’s what OP actually meant to report?

Yes, It's strange that there are two different font with the same .ass file

@vxzms
Copy link

vxzms commented May 13, 2021

I misunderstood the issue.
I mistakenly thought this are two problems, one is XySubFilter_libass bug, another fix in b9f3468. the commit can‘t fix it. I paid more attention to the first one.

@astiob
Copy link
Member

astiob commented May 13, 2021

To be fair, that did diagnose a real issue with XySubFilter_with_libass, so that’s useful too :-) Its GitHub repo has issues disabled, so, uh, @Masaiki, it needs to call ass_set_storage_size. But ideally this discussion should continue somewhere else.

@Masaiki
Copy link

Masaiki commented May 13, 2021

To be fair, that did diagnose a real issue with XySubFilter_with_libass, so that’s useful too :-) Its GitHub repo has issues disabled, so, uh, @Masaiki, it needs to call ass_set_storage_size. But ideally this discussion should continue somewhere else.

Well, i will try to handle it.

@TheOneric
Copy link
Member

TheOneric commented May 13, 2021

@MatiasMovie You're currently using the DIrectWrite font provider, but apparently your binary is built with support for fontconfig as well. To help us determine which font-providers are affect by this, could you run mpv with fontconfig and logs? So you would invoke mpv like this (replacing filename.mkv with the actual name; maybe also mpv.exe instead of mpv):

mpv --sub-font-provider=fontconfig  --log-file=mpv-log-fontconfig.txt  filename.mkv

If that's the first time you're ever using fontconfig on Windows you may experience a freeze/lag at the beginning while fontconfig is initialising its cache, please just wait a bit if that happens.
Once the video actually played the line from the previous screenshots, please tell us what font was selected (or post another screenshot) and upload the new log file.

You don't need to worry about the mpc-be logs, I've since been told they don't contain font-related stuff anyway.

@MatiasMovie
Copy link
Author

Once the video actually played the line from the previous screenshots, please tell us what font was selected (or post another screenshot) and upload the new log file.

image
mpv-log-fontconfig.txt

@Masaiki
Copy link

Masaiki commented May 14, 2021

the problem occured on lines 650 to 667 of file https://github.com/libass/libass/blob/b9f34688f6ef1988136ba5e90a91ae8ac9b8a55f/libass/ass_fontselect.c
libass first matches the font from the fonts that has been loaded, and if no font is matched, call the match_fonts function of provider.
So here, the font in mkv partially matches the name in ass, match_fonts is not called.

@astiob
Copy link
Member

astiob commented May 14, 2021

Yes. See #509 (comment) above.

@TheOneric
Copy link
Member

TheOneric commented May 14, 2021

Thanks for testing with fontconfig, MatiasMovie.
However, after some more testing and digging, it turns out our fontconfig is not affected by this, and usually does find the regular font-variant. But the mpv-build by shinchiro your using does ship a custom fontconfig-config-file, which prevents fontconfig from loading system fonts, which is why you're still getting the bold font.
(To shinchiro build users: preventing system fonts from being loaded by default seems a bit odd to me, but I'm not using this and don't know what considerations went into it. If you know more about that and think that should be changed, please file a bug at: https://github.com/shinchiro/mpv-packaging/issues the file is located at mpv-root/mpv/fonts.conf)

So it's just like astiob suspected: CoreText and DirectWrite are affected, fontconfig is not.

@MatiasMovie
Copy link
Author

Ok, Thanks for the detailed explanation @TheOneric

@astiob
Copy link
Member

astiob commented May 6, 2022

After some discussion on IRC, it seems likely that we may keep the new behaviour as an intentional feature and adjust the Fontconfig backend to match, because it’s apparently common for fansub authors (typesetters) to have only a subset of a font family installed during authoring, which is then attached to the released MKV file and should be preferred during playback even if the end user does have more fonts installed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants