sub/osd/console: adjust font sizes

[kasper93]

No description provided.

[kasper93]

For osd-msg it is bigger than youtube, for sub-font_size it is the same as youtube. Similar to other VOD platforms.

(remember it scales with window height, so those screenshots are only valid when viewed unscaled. But point about the huge font is the same)
Before:

After:

EDIT: Also note that OSC elements are fair bit smaller, so there is not point in making osd/sub font unproportionally big and instead used should adjust the scale as a whole.

[github-actions]

Download the artifacts for this pull request:

Windows

• mpv-i686-w64-mingw32
• mpv-x86_64-w64-mingw32
• mpv-x86_64-windows-msvc

macOS

• mpv-macos-13-intel
• mpv-macos-14-arm
• mpv-macos-15-arm

[llyyr]

This needs to update docs as well

[norinoriko]

I know that the stats font size has to remain 20, but maybe the font outlines should be thinned out? If the purpose here is to have visual parity, they look a little thick now in comparison to the rest of the elements. Either that, or the font outlines for everything else (osd, console etc.) should be thicker.

[kasper93]

This needs to update docs as well

Done.

I know that the stats font size has to remain 20, but maybe the font outlines should be thinned out?

Good catch, it was twice as thick. Fixed.

[kasper93]

For sub-font-size, we could go for 45, this is common size for blu-ray PGS subtitle font. In fact I was using 42 myself, so maybe 30 is bit too big of a change. But for others 30 seems fine. Also like I said before 30 for sub size is still quite comparable to common VOD platforms, blu-ray subs are generally big guys in this comparision, so that's why I'm opting to unify everything at 30.

[norinoriko]

I think a larger sub font would be preferred most of the time for readability reasons. I would assume most users treat the subtitles and player OSD as separate things, in which case they're not really expecting consistency.

[kasper93]

I think a larger sub font with thicker outlines would be preferred most of the time for readability reasons. I would assume most users treat the subtitles and player OSD as separate things, in which case they're not really expecting consistency.

I’m well aware. I don’t have the resources to gather information on how people prefer subtitles. However, from what I’ve observed on VOD platforms, default subtitle sizes are generally smaller than the 30 size proposed here. That’s why I think this size makes a good default target, it can be adjusted as needed, remains readable, and doesn’t obscure too much of the video. Of course, subtitle size is a matter of personal preference, and everyone is welcome to adjust it as they like. We won't be able to find a value to wroks for everyone, but at least we can find one that is consistent across mpv text display.

EDIT: For the record, I really think both OSD and subtitle default font size is too big. Sure it is preference, but I doubt majority of users need that big text is we consider recommended viewing distance.

[norinoriko]

However, from what I’ve observed on VOD platforms, default subtitle sizes are generally smaller than the 30 size proposed here.

I think it's fair to point out that some streaming services use a sub border that is akin to background-box, which probably assists with legibility in those cases. So it's not just a matter of font size, the outline/border has to be accounted for as well. Especially when we're talking about something that people are going to be staring at for 1-2+ hours, as opposed to the OSD which only appears momentarily and should be out of the way of the viewport as much as possible.

I don't use mpv's default sub styling so I'm not here to block any changes either way. I do agree that the default is too large.

[na-na-hi]

The purposed value is problematic for both cases:

• 30 is too large for console. On a 4:3 or 16:10 screen, it can't even show 80 characters per line.

• 30 is OK for OSD, similar to default MPC-HC. However, MPC-HC like many VOD platforms draws a background box behind OSD, so the readability is significantly improved. I personally use background-box for OSD style because the default is unusable when watching videos with lots of text content, especially when these texts also have borders.

So I think the console's font size should stay unchanged for now, and if the OSD font size is made smaller, also draw a semi-opaque background to ensure readability.

[guidocella]

Outline sizes could be left at 3 for better readability, that's what I still use with font-size=30.

[kasper93]

We have a fairly large outline to improve readability. I think the readability issue with the "text on text" scenario is somewhat separate from what we're addressing here. I understand that a smaller font may blend better, but under normal circumstances, it remains readable with the current outline value.

I actually like the idea of a background box for the OSD, but this falls slightly outside the scope of just "changing font size." It would be a nice QOL addition, but if we go this route, it might be worth designing a more refined style for the OSD "box" rather than just adding a background box.

30 is too large for console. On a 4:3 or 16:10 screen, it can't even show 80 characters per line.

That's a valid point. The 16:10 aspect ratio works well, in my opinion; 4:3 is indeed too square. I prefer 24 for the console, but since it's the same for select.lua, I'm thinking there's no reason not to use the same size as the OSD. We could revisit the idea of having a different font configuration for select, but that would add complexity.

like many VOD platforms draws a background box

Not all of them though. But I agree background box is ultimate readability.

Outline sizes could be left at 3 for better readability, that's what I still use with font-size=30.

I think it’s too large. I tested it with various sizes, starting at 2, then 1.8, and finally settling on 1.62, which maintains the same proportional outline size to font size as before. It doesn’t look great when the large outline starts creating a background box effect.

EDIT:

If we don't want to use the same size everywhere. I'm thinking something like.

	font_size	outline_size
console	24	1.32
select	24	1.32
stats	20	1.1
sub	32	1.76
osd	32	1.76

[norinoriko]

If everyone else is fine with the sub font being small, then I think keeping both the osd/sub at 30 is fine. As for outlines, I think 8% is an OK compromise between guido's 10% and this PR. Smaller outlines tend to alias on certain displays so I think it's fine (maybe even desirable) if the outline creates a "background box" effect in this case.

However, if everyone is moving in the direction of having a background-box behind all of the OSD text in the future, then I think going back-and-forth about the outline size shouldn't block this PR, since I would be more in favor of disabling outlines (0.0) completely to match the OSC styling. With a sufficiently opaque background-box (#B0000000), the text is still very much legible without outlines, and it looks cleaner overall.

[kasper93]

Changes:

• Applied current values to the PR:

	font_size	outline_size
console	24	1.32
select	24	1.32
stats	20	1.1
sub	32	1.76
osd	32	1.76

• Reduced sub/osd margin to 15/15
• Reduced opacity of OSC box
• Added profile=osd-box to add easy option to switch osd style to one with bacground-box, which was suggested in this thread.

[norinoriko]

I'll keep my thoughts so far short:

• The osd-shadow profile is a bit ugly because the blur causes this white radial effect around text. Not sure if I'm a fan of it, but maybe someone is.
• Maybe my display sucks or I just have terrible eyesight, but 40% opacity with osd-box still makes me squint and double-take depending on what's in the background. Maybe @na-na-hi has a suggestion for this since he already daily-drives background-box apparently?
• (nitpick) - --osd-font-size=30 is a little bit more cohesive (+25% of console, +50% of stats) than 32. It's not that much bigger than 30, so it wouldn't have really made subtitles any more legible. I still think staying with the smaller number here is better.

Outside of that I can't really think of anything else.

[kasper93]

The osd-shadow profile is a bit ugly because the blur causes this white radial effect around text. Not sure if I'm a fan of it, but maybe someone is.

This was a quick try at shadow. This needs optimizing and fixing, since for example osd-bar breaks with it. I will skip it for now, maybe we can provide such profile in the future. I personally instead of shadow, background-box with little blur to the border, but this doesn't work, as the blur is applied to text/outline and would need custom drawing which is outside of the scope of this PR.

Maybe my display sucks or I just have terrible eyesight, but %40 opacity with osd-box still makes me squint and double-take depending on what's in the background. Maybe @na-na-hi has a suggestion for this since he already daily-drives background-box apparently?

I'm not sure if blending looks the same on each platform. But 40% is of course on lower side, might go with 60%.

---

I think I will add small osd-blur=0.4 and make default outline larger. It actually looks a lot better to me, than simple outline.

[guidocella]

I think I will add small osd-blur=0.4 and make default outline larger. It actually looks a lot better to me, than simple outline.

This comes from what I use my with my outline size, I guess I should have mentioned it. You want a bigger border size with blur.

[norinoriko]

55% seems reasonable.

With the more opaque box, maybe this PR should also bring back the OSC opacity commit? I think it makes sense now to change boxalpha to 115, and then maybe convert osd-back-color to a matching hex (255-115=140 => #8C000000) so that the styles are more "unified" as well. I think it looks nice, at least. *shrug*

[kasper93]

55% seems reasonable.

With the more opaque box, maybe this PR should also bring back the OSC opacity commit? I think it makes sense now to change boxalpha to 115, and then maybe convert osd-back-color to a matching hex (255-115=140 => #8C000000) so that the styles are more "unified" as well. I think it looks nice, at least. shrug

Done.

[kasper93]

Just a note about subtitle size: subtitles are scaled according to the height of the viewport, depending on the blend-subtitles option. When blend-subtitles=yes, the video height is used, while blend-subtitles=no uses the full height, including black bars. Therefore, subtitles will appear smaller than the OSD if black bars are added and blend-subtitles=yes is set.

I think the current size works in both cases, but I can also imagine that some users might want to increase it. Although we won’t find a perfect option for every scenario, my goal is to create something that works well out of the box, meaning it’s "usable" and can be adjusted if needed.

[na-na-hi]

I tested the osd-shadow profile and the readability is the lowest among all profiles here especially on bright backgrounds, and the performance is horrible due to huge blur radius, resulting in framedrops.

Also what's the reason to introduce a default osd blur here? This kind of "glowing text" blur doesn't fit into contemporary design language, and it slows down rendering by ~15% compared to no blur on 1080p screen. On a 4K screen the performance loss would be even higher due to larger blur radius.

IMO there should be no blur by default and the osd-shadow profile shouldn't exist.

[kasper93]

Updated. Like I said before, I don't like the shadow profile either, it would have to be tuned better, it was quick experiment to try it out, because we cannot blur background-box, which would imho be preferable.

[sfan5]

can we start by fixing the font size and then discuss any other possible adjustments?
it's also hard for me to tell what has been changed by this pr without testing myself.

[kasper93]

Per @sfan5 request, I removed box profiles.

EDIT:

it's also hard for me to tell what has been changed by this pr without testing myself.

It would be best if you tested yourself and see the changes. I'm interested in feedback.

[sfan5]

It would be best if you tested yourself and see the changes. I'm interested in feedback.

I plan to, but screenshots are very convenient if I have a spare 5 minutes to look at github.

[sfan5]

👍

[Akemi]

i am fine with all the changes. though personally think the new sub font size is way too small. i also don't consider VOD services a good indicator what is good tbh. though coming from an anime fansubber background, sub font sizes are generally chosen fairly big. i would also say usual VOB or PGS subs are a better indication what the size should be.

subs should not deviate your attention from what is happening on the screen or rather the most important part the center.

• they shouldn't be too small and should have enough margin, so they don't deviate your view to the bottom (or any kind of side)
• they should also not distract or hide the center
• they need to be eligible on any kind of background
• ...

choosing a sub font size also depends on your viewing habits and environment. like TV or PC monitor, distance to screen, sub or dubtitles (support for actual the spoken language or actual translation), etc.

i would say the new one totally falls into the too small and not enough relative margin category.

anyway, i am not sure if we want to discuss this any further or more extensively. anyone probably has their own preferences in that regard and should have configured appropriate sub setting for themselves (at least i did this myself many years ago). so i am not planning to block this change. just wanted to state my opinion on that and i am fine with what is chosen in the end.

[edit]
some general resources, though there are/were probably more/better ones:
https://github.com/zeriyu/fansub-guide/blob/master/pdf/styling-guide-underwater.pdf
https://kaleido-subs.github.io/style-guide/guidelines/styling/dialogue_styling/
https://github.com/zeriyu/fansub-guide?tab=readme-ov-file#styling-theory

[avih]

It's impossible to make everyone happy, but personally I prefer bigger margins (x and y) and a bit bigger text, and a bit thicker border.

The margins are important to have good spacing at the sides. The goal is not to fit as much as possible, but make it comfortable to look at.

Though obviously all of those can be very subjective.

[kasper93]

i am fine with all the changes. though personally think the new sub font size is way too small. i also don't consider VOD services a good indicator what is good tbh.

I don't understand why not, this is the majority of the consument content nowadays, by a lot margin. But let's not go there, not important really.

though coming from an anime fansubber background, sub font sizes are generally chosen fairly big. i would also say usual VOB or PGS subs are a better indication what the size should be.

Ok, I've updated to be comparable to PGS subtitle size in nominal 16:9 use-case. I've also increases the margin-y to make subtitles positioned in more present to read position.

It's impossible to make everyone happy, but personally I prefer bigger margins (x and y) and a bit bigger text, and a bit thicker border.

The margins where fixed. The border is proportional to what we had. We have significantly bigger outline than generic PGS subs, already.

mpv (this pr)

PGS (some movie):

good spacing at the sides

Neither old or new spacing will help with that, it is just to not overflow on the sides in x-dimension. It is on subtitle to break lines in sane way.

Though obviously all of those can be very subjective.

All of this is highly subjective, or I would say even if we agreed on objective measures, we cannot set one size to rule them all. Because of different video/window aspect ration, blend-subtitles, sub-use-margins options and target content. It really depends, for example sometimes you may want to put subs above black bars, but then you want to not have too big of margin for cropped sources and so on.

I initially wanted to unify the sizes, but this has proven to be impossible. Now the goal is to make it less huge, but with the similar feeling.

[Akemi]

please don't misunderstand. i am not trying to start an argument, just trying to answer your questions or give some information/insight. over the past 2 decades i read many documents about that topic and a lot of the information is just stuck in my head and i might not be able to cite the source anymore. it is fine to disagree.

I don't understand why not, this is the majority of the consument content nowadays, by a lot margin. But let's not go there, not important really.

i am of the opinion, just because it is supposedly the "majority" doesn't make it more right. there is also more the lack of the consumer to actively care about subtitles.

here we have to also keep in mind, subtitles existed way before VOD (so majority is time relative here i would say). many VOD services broke with some regular accepted subtitles rules and many subtitles were just an afterthought. in comparison the BBC conducted several surveys and wrote several white papers about subtitling over the decades. they probably started when teletext was invented and used for subtitling TV broadcasts.

this document (https://www.bbc.co.uk/accessibility/forproducts/guides/subtitles/) answers many questions, like size (line height 8% of the height of the video, 720p > 57.6), legibility, subtitle consumer ratios (10% broadcast 35% on some online content), etc. it got many revisions over the decades and isn't really in the state it was when i first came about it. though still think many of the informations are relevant and do have a certain 'scientifically' value.

We have significantly bigger outline than generic PGS subs, already.

totally true and unfortunate. the good old (yellow) DVD VOB subs had a way bigger outline. this got kinda changes with the advent of PGS subs/higher resolutions. the BBC for example recommends a background instead of an outline (that as a side note and probably because of the limitations of teletext). on more modern/newer subtitles this was adapted to be a thicker outline and/or shadow, to make the subs pop out more/make them more legible on different backgrounds.

It is on subtitle to break lines in sane way.

sorry if i misunderstand this statement. there are long arguments about hard- and soft line breaks (render decides where to break). though in general, if you use something like ASS/PGS/VOB subtitles it's fine to use hard line breaks, since your subtitles are not supposed to change relative size (size is fixed and scaled). though for something like SRT where the size is configurable hard line breaks are disadvantageous. this can lead to unwanted line breaks. as an example a line with two lines could turn into a three liner (three lines are discouraged) when sizes of the subs increased, when a hard line break is used.

-------------------| <<assuming this is the end of the visual horizontal right possible subtitle length, when a soft line break would happen
bla bla bla bla\n
bla bla

increasing in font size could lead to. we got a three liner but only need two lines still
-------------| 
bla bla bla 
bla\n
bla bla

All of this is highly subjective

i don't think all of this is subjective. with many things it's a mix of both (or not everything is black and white) and how much the individual person cares. i think the resources i linked are a good start and some objectives measures can be extracted from.

[kasper93]

please don't misunderstand. i am not trying to start an argument

It's fine, I value your input on the topic.

i don't think all of this is subjective. with many things it's a mix of both (or not everything is black and white) and how much the individual person cares. i think the resources i linked are a good start and some objectives measures can be extracted from.

This was bad wording, what I in-fact meant it is highly dependent on user viewing environment and on-top of that there are also personal preferences.

this document (https://www.bbc.co.uk/accessibility/forproducts/guides/subtitles/) answers many questions, like size (line height 8% of the height of the video, 720p > 57.6)

I just want to start with saying that teletext subtitles are inherently limited in its rendering, and with that out of the way.

I think it is disingenuous to quote only this value, as it is even not what we are suppose to use. This is the MAX authoring size of the subtitles.

The 8% value originates in Teletext, where it is approximately the height of a double height line, with the Teletext rendering area covering around 90% of the video area height

Depending on device size, viewing distance, screen resolution etc., a processor (such as a player) may choose to reduce (but not to increase) the authored font size so that the final presentation font size is smaller than the authored font size. For example, on a very large TV the subtitles may appear too large when displayed at the original authored size, so the processor can apply a scaling factor, or a multiplier of less than 1

For most screen sizes, the preferred font size is between 0.6 and 0.8 times the required authoring font size. For small mobile phones (e.g. 4" diagonal screen size) the presentation size should be the unmodified authored font size (i.e. a multiplier of 1).

Note that I'm targeting normal sized devices, not mobile phones, that would be the job for mpv-android.

Looking at this table, we see that the recommended range is 0.5 to 1.0 (>28.8), with values of 0.6 (34.56) for desktop PCs and 0.67 (38.592) for 32"-42" TVs. Note that 32"-42" TVs are very small by today’s standards.

If we take a value of 0.6, then 0.6 * 57.6 = 34.56, which is close to my initial suggestion of 32. This also matches what YouTube uses for their subtitles, indicating that VOD platforms do follow certain guidelines.

Initially, I wanted the same font sizes for OSD and SUB, which is why SUB ended up being smaller. I realize now that this doesn’t work well, as having the same size for both isn’t effective. OSD shouldn't be as large as SUB.

After reviewing these recommendations, we could even consider a size range of 38-40 instead of 42, which still feels a bit large, in my opinion.

---

Side note. Public broadcasters from my region is providing both teletext and dvbsubs. And it is quite obvious why teletext is nominally quite big and the dvbsubs have more reasonable size. (and still suppose to be scaled)

(ignore encoding issue, zvbi doesn't detect correct encoding)

As we can see, teletext font rendering limitations pushes some decisions on size... (And yes, our current size (this pr) is similar to dvbsub, though more flat)

[Akemi]

I think it is disingenuous to quote only this value, as it is even not what we are suppose to use. This is the MAX authoring size of the subtitles.

sry totally my bad, this was misleading. i didn't mean it as an answer for our problem specifically but rather the answer/reason why they decided on that size. i thought i would go a bit overboard quoting everything.

indicating that VOD platforms do follow certain guidelines.

sry, i didn't mean to imply they don't do that at all.

Note that 32"-42" TVs are very small by today’s standards.

since it's is also recommended to adjust your viewing distance according to the size (and resolution of content) you are viewing, the size shouldn't matter that much in that regard. but yeah in practice most wouldn't really do that and they have a 'fixed' distance (i am probably an oddball) and then the size matters. also a reason why there is a recommended range.

After reviewing these recommendations, we could even consider a size range of 38-40 instead of 42, which still feels a bit large, in my opinion.

i always read those tables, infos and recommendations the other way around. eg start with the largest multiplier as default (x1) and make the rest user adjustable by the recommended range. the recommended multiplier always seemed like a value they decided on by assuming certain things (not criticising this decision, they have to assume certain things) that are in the hand of the user itself, like viewing distance, content viewed (which can be related to the viewing distance), etc. differently said, all devices are 'unknown' devices since their relative size is dependent on the viewing distance.

anyway or rather some rambling, decreasing the size is less likely to break something (see line break example above) than increasing. so in my mind i always start at the biggest size recommended.

TLDR
but yeah, like you mentioned before we are now entering the area of personal viewing environment and personal preferences. anything falling inside the recommended range should be as good a default value than another. since the most common recommended range (from this table) is x0.67-x1, it should probably be at least x0.67.