There's several path-related options that do not handle common shortcuts
(like ~/). Fix this by using mp_get_user_path where appropriate which
expands the path so users get more intuitive behavior. Fixes#15598.
Taken from the last freely licensed version of Symbola and manually
adjusted the number in the glyph file to match the adjacent arrows.
Saving sfdir with fontforge also automatically removed the O flag from 2
existing glyphs. According to
https://fontforge.org/docs/techref/sfdformat.html "O" just meant "the
character was open when last saved", so it doesn't change anything
visible.
By default OSD and subs have no shadow, but if you do set a
--osd/sub-shadow-offset, the current default white shadow color looks
bad around white text with black border. Default to semitransparent
black instead. Use the same color box profiles were using to allow
removing it from there.
Previous fixes in bcc3d72 make subtitles on videos with non-square pixel
aspect ratios appear incorrect. This can happen on subtitles for SD
Blu-rays where the video resolution is 720x480 but the aspect ratio is
4:3. The scaling still applies when the video frame is cropped with
filters so the previous fix will still work.
Fixes#15415.
The current OSD font size is excessively large, causing most
messages—except for very short ones to overflow horizontally.
I conducted testing across multiple devices of varying screen sizes and
under different scenarios. The adjusted font size strikes a good balance
for readability on non-high-DPI displays, while high-DPI displays should
utilize DPI scaling as needed.
Additionally, I compared the font sizes of subtitles and UI elements
across various VOD platforms, which generally use smaller font in most
cases.
The current sub font size was significantly larger than even PGS
subtitles, which are quite large on their own. Now, they are comparable.
The subtitle font size was chosen based on recommendations from the BBC
Subtitle Guidelines. It is set to 8% of the video height with a
recommended scaling factor of 0.67. Therefore, at 720p (the reference
size for mpv font scaling), the calculation is 8% * 0.67 * 720 = 38.592,
rounded down to 38. This value falls within the recommended scaling
range of x0.5–x1 for desktop PCs/Laptops and TVs (32"–42"). For more
information, see
https://www.bbc.co.uk/accessibility/forproducts/guides/subtitles/#Presentation-font-size.
OSD font size is smaller than font as those elements shouldn't be
distractful and only noticable when the user wants to look at them.
Outline size is set to 5.5% of font size.
High --osd-blur values break the osd-bar by not drawing the filled
portion, and even low values just make it look worse, so don't apply
--osd-blur to the osd-bar.
Disabled by default because it breaks sub-seek and playback in cases
where the user changes play-dir from + to - during runtime and past
"seen" events need to be re-rendered.
Available since dcc9eb722e
This adds --osd-bar-marker-style option which can be used to
customize OSD bar marker style. In addition to the existing triangle
style, a new style option is added to draw markers as lines.
If show-text ${playlist} is used with --osd-scale-by-window=no while
printing to the terminal or while mpv is starting, the out_screen_h
assignment in osd_get_text_size() causes runtime error: signed integer
overflow: 288 - -2147483648 cannot be represented in type 'int'. Fix
this by not making prepare_osd_ass() use an infinite playresy.
This prevents printing show-text ${playlist} without a line limit to the
terminal with --osd-scale-by-window=no, which makes only the last
playlist entries be printed, and the selected one is not printed if it
isn't among them. A later commit will make the line calculation
accurate.
A packet with an unknown duration flagged the entire context and then
this was saved forever throughout the entire lifetime of the object.
This inherently doesn't work with the redecoding sub logic which will go
through all the packets again. So the second time around, packets with
known durations get treated as if they were unknown and things go awry.
Rework this so it is per packet like it should be and not a global
state. Note that f9cefbfec4 originally
added this for specifically eia-608 subtitles but their packets are all
detected as unknown anyway due to the durations so this is not needed
anymore and interferes with other things.
ASS_OVERRIDE_BIT_STYLE includes ASS_OVERRIDE_BIT_ATTRIBUTES, which we
don't want.
This prevents --sub-ass-override=force from overriding attributes such
as bold, italics, underline or strikeout to mpv defaults.
Ideally it should be fast, it is on VO thread and steals precious frame
time budget. Looks like this is one of the main reasons why
display-resample on higher refresh rate displays is too slow.
It is unclear whether there actually is any usecase for this option
which isn't better served by sub-ass-use-video-data and/or LayoutRes
overrides, but prior to the introduction of sub-ass-use-video-data
it was possible to pass along storage resolution while faking an
aspect ratio of 1:1.
sub-ass-video-aspect-override=1 combined with sub-ass-use-video-data=all
now makes this possible again.
The uper limit of a 10:1 aspect matches
the general video-aspect-override option.
The naming for "blur-compat" was misleading since the setting
actually affects more than just blur affects. Additionally
forwarding storage resolution but forcing an aspect ratio
of 1.0 for the video is likely to result in odd rendering
and there’s no known usecase for it.
Both options control which video properties are exposed to libass
so to fix the aforementioned issues merge these settings into one
tri-state sub-ass-use-video-data.
The default V keybind now cycles through all states of
use-video-data instead of toggling vsfilter-aspect-compat.
Resolves: https://github.com/mpv-player/mpv/issues/10680
--sub-margin-y is documented to scale with font size, which is scaled
"by" or "with" window depending on the options. However, when using
ass_set_font_scale to change font size, the y margin isn't scaled, so it is
still scaled to video size. This causes the y margin size becoming smaller
when the video becomes smaller, even when the font size isn't changing.
Fix this by also scale the MarginV with the font scale. Also use lrint
instead of round.
By default, libass scales subtitle with video size.
When --sub-scale-with-window is enabled, mpv attempts to undo this scale
and use window size instead. However, the current bahavior is incorrect
when use_margins is enabled, because in this case libass uses the size
of video as if it's "fit" to the window, instead of the displayed size.
As a result, subtitle scale is broken when video-zoom is used in this case:
when zooming out video, the subtitle is scaled up.
Fix this by using the correct factor when use_margins is enabled.
Using strchr should be faster as it is optimized for the job. Also
ensure that tags are not escaped and are within {} correctly. This also
is important for performance as it allows to scan only needed areas of
the string.
Co-authored-by: Avi Halachmi (:avih) <avihpit@yahoo.com>
Co-authored-by: rcombs <rcombs@rcombs.me>
4e5d996c3a added this as part of a series
of patches written to avoid wasteful sub redraws when playing a still
image with subs. The is_animated special case was specifically for ASS
subtitles that have animations/effects and would need repeated redraws
in the still image case. This check was done unconditionally for all ASS
subtitles, but for very big ASS subtitles, this text parsing can get a
bit expensive.
Because this function call is only ever needed for the weird edge case
of ASS subtitles over a still image, some additional logic can be added
to avoid calling is_animated in the vast majority of cases. The animated
field in demux_packet can be changed to a tristate instead where -1
indicates "unknown" (the default state). In update_subtitle, we can look
at the current state of the video tracks and decide whether or not it is
neccesary to perform is_animated and pass that knowledge to sd_ass
before any subtitle packets are decoded and thus save us from doing this
potentially expensive call.
Users shouldn't have to care if subtitles' duration is unknown because
the only difference is that decode() sets a duration to packets without
one, if any.
The main difference was code intentionally breaking sub-seek, sub-step,
sub-start and sub-end for unknown duration subtitles for some reason,
but I removed it in 0f2370476b and 185fa9ffc6.
LRC subtitles always have unknown duration so if you use them having
this logged on every song is annoying, so only log it in verbose mode.
With multiple rects touching each other without any gaps, the current
scale method can cause gaps or overlaps between rects. To make sure that
this does not happen, scale on the edges of the rects instead, and then
calculate the width and height from the results.
NB: while this is better than the status quo, it does not fix all
scaling artifacts because of the following:
- When two rects share a vertical edge but have different heights,
misalignment will occur: after rounding rect heights to pixels,
the height scale factor for the two rects will be slightly different.
As a result, there will be misalignment between the scaled images.
- With a GPU renderer, different bitmap subtitle parts are rendered as
different textures. This means that the pixel contents of the parts have
different boundary conditions from the whole combined image. As a result,
there will still be small gaps when the subtitle is scaled up.
The only way to properly address these points is to make sure that the
parts are combined to a single image at the native resolution before
being scaled. This can be partly achieved with --blend-subtitles=video.
