libass: 0.15.1 breaks ffmpeg subtitle burning with utf-8 glyphs for osx
db85ef4736108c12bf3e12939447840815c246ec introduced an issue when trying to burn in non-english srts.
with:
ffmpeg -i "test.mkv" -vf subtitles='test.srt' -c:a copy -c:v h264_videotoolbox -b:v 8000k -map 0:v:0 -map 0:a:0 'out.mkv'
and:
1
00:00:03,125 --> 00:00:06,375
你好世界
results in:
[Parsed_subtitles_0 @ 0x7fc863206fc0] fontselect: (Arial, 400, 0) -> /System/Library/Fonts/Supplemental/Arial.ttf, -1, ArialMT
[Parsed_subtitles_0 @ 0x7fc863206fc0] Glyph 0x4F60 not found, selecting one more font for (Arial, 5, 400)
[Parsed_subtitles_0 @ 0x7fc863206fc0] fontselect: failed to find any fallback for font: (Arial, 400, 0)
[Parsed_subtitles_0 @ 0x7fc863206fc0] Glyph 0x597D not found, selecting one more font for (Arial, 5, 400)
...
when it’s working, it should’ve done this:
[Parsed_subtitles_0 @ 0x7f99e8206380] fontselect: (Arial, 400, 0) -> /System/Library/Fonts/Supplemental/Arial.ttf, -1, ArialMT
[Parsed_subtitles_0 @ 0x7f99e8206380] Glyph 0x4F60 not found, selecting one more font for (Arial, 5, 400)
[Parsed_subtitles_0 @ 0x7f99e8206380] fontselect: (Arial, 400, 0) -> /System/Library/Fonts/PingFang.ttc, -1, PingFangSC-Regular
dev env instructions:
brew install ffmpeg
brew unlink libass
# make your debug build
ln -snf `pwd`/libass/.libs libass/lib
ln -snf `pwd`/libass /usr/local/opt
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 2
- Comments: 16 (8 by maintainers)
Commits related to this issue
- fontselect: match whole typographic family on fallback Currently implemented for directwrite and coretext. This improves fallback font choice by considering the whole extended family. This also fix... — committed to astiob/libass by astiob 3 years ago
- fontselect: match whole typographic family on fallback Currently implemented for directwrite and coretext. This improves fallback font choice by considering the whole extended family. This also fix... — committed to astiob/libass by astiob 3 years ago
- fontselect: match whole typographic family on fallback Currently implemented for directwrite and coretext. This improves fallback font choice by considering the whole extended family. This also fix... — committed to astiob/libass by astiob 3 years ago
- fontselect, coretext: match whole extended family on fallback Currently implemented only for coretext, but other providers may/should add this later. This improves fallback font choice by considerin... — committed to astiob/libass by astiob 3 years ago
- fontselect, coretext: match whole extended family on fallback Currently implemented only for coretext, but other providers may/should add this later. This improves fallback font choice by considerin... — committed to astiob/libass by astiob 3 years ago
- fontselect, coretext: match whole extended family on fallback Currently implemented only for coretext, but other providers may/should add this later. This improves fallback font choice by considerin... — committed to libass/libass by astiob 3 years ago
- fontselect, coretext: match whole extended family on fallback Currently implemented only for coretext, but other providers may/should add this later. This improves fallback font choice by considerin... — committed to astiob/libass by astiob 3 years ago
Very interesting. Thanks for the debugging!
Indeed, it fails to find the font for me if I request 蘋方-簡 (the traditional-characters name). But it does find it if I use 苹方-简 (the simplified-characters name). This happens even if my language preferences have Traditional Chinese before Simplified.
I can fully reproduce your report if I move Simplified Chinese above Japanese in my language preferences.
Curiously, if I move Traditional Chinese higher up, Core Text supplies PingFang TC as the fallback. That font, too, has traditional and simplified names, in the same order, but this time Core Text only finds it by the traditional name and fails lookup by the simplified name, again regardless of my language preferences.
I’ve also just noticed (…when I started writing this comment a few hours ago) that the commit you mentioned in the original report is the 0.15.1 regression fix commit; and yet I asked you to check that you weren’t seeing the regression that it was supposed to have fixed. Whoops.
Welp. Looks like Core Text’s
CTFontCollectionCreateMatchingFontDescriptorshonours at most one “unlocalized” and one “localized” name for each font. I’ve spent the night digging, but I’ll dig some more.I get:
Naming the specific font explicitly works, too: