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.
This fixes converted subtitles that are styled.
This reverts commit 5e2c211a4e.
Most of the subtitle decoders in libavcodec sets meaningful style
values. For the rest we can conditionally strip style.
Enable ASS_FEATURE_{WHOLE_TEXT_LAYOUT, BIDI_BRACKETS} and auto base
detection by default, and add an option to disable this if needed.
This is strictly an improvement for webvtt files as they always use
auto base detection. This _fixes_ right-to-left text rendering for
webvtt files which correctly mark rtl/ltr. Webvtt files obtained from
sources which sideload the RTL information through css also see an
improvement due to the auto detection.
Generally SRT files also want this, but some are also written to
workaround VSFilter quirks.
See also: https://github.com/mpv-player/mpv/pull/12985#issuecomment-1839565138
92a9f11a0b added locking for dec_sub.
At that time, because the lock was exposed to the outside world,
a recursive mutex was used. However, this is no longer true after
e9e883e3b2, when the public locking
functions were removed. This means that the lock is now private.
Unlike input.c, dec_sub already enforces said call hierarchy, so
combined with the aforementioned change, the lock is only ever
called once and never recursively. Thus the lock can be converted to
a normal mutex.
Depending on the options:
For AV_CODEC_ID_ARIB_CAPTION this allows using bitmap output.
For AV_CODEC_ID_DVB_TELETEXT this allows using text output.
Fixes: #13471
This adds a command to escape ASS tags to remove code duplication
between sub/osd_libass.c, console.lua, osc.lua, stats.lua and any user
script that calls mp.create_osd_overlay().
A command is used instead of scripting functions so that all clients can
use this and not just use Lua and JS ones.
osd_mangle_ass() also interprets osd-sym-cc and osd-ass-cc/{0,1}, but
since they use invalid UTF-8 characters there is no risk of escape-ass
users using them by accident, like with any OSD message.
Always replacing \n with \\N in mangle_ass() even when it is not called
by escape-ass doesn't seem to cause any issue, but I made it conditional
anyway to avoid changing how all OSD messages are treated unnecessarily.
0b35b4c917 originally introduced sd_filter
to make a more general subtitle filter infrastructure. But when doing
so, it directly sets ft->event_format to ass_track->event_format in the
struct. The lifetime of ass_track and the sd_filter are not equivalent
which makes it easy to trigger undefined behavior. Notably, commit
cda8f1613f introduced assobjects_destroy
which can destroy ass_track anytime during runtime which means that the
string in ft->event_format is actually freed and should never be used.
Remedy this by simply doing a proper strdup when the filter inits with
ft as the parent so we avoid this scenario altogether. Fixex #13525.
An ass event like `{\p1\pos{1,1}}m 0 0 l -3 -7 l 11 -7 l 11 -2` ends
the drawing mode started with `\p1` due to `\pos` gets confused with
`\p`, and thus that line is wrongly considered to be visible text.
LRC subtitles can have lines with multiple timestamps, e.g.
[00:00.00][00:02.00]foo
[00:01.00]bar
Currently mpv shows only the "foo" that was decoded first, because it
compares the packet file position to check if a packet was already seen,
and it is the same for both occurrences of "foo". Fix this by also
comparing the pts.
This keeps comparing the packet position on top of the pts to not break
subtitle lines with the same timestamp, like:
1
00:00:00,000 --> 00:00:01,000
foo
2
00:00:00,000 --> 00:00:01,000
bar
where mpv shows both lines on top of each other. They are common in ASS
subtitles.
Fixes https://github.com/mpv-player/mpv/issues/13497.
When using sub-seek without a video track while paused, adding the 0.01
SUB_SEEK_OFFSET to the new timestamp is not enough to show the new
subtitle line. Add 0.1 instead to fix it. 0.01 is already enough for
sub-step.
The previous commits optimized sub redrawing on still images/terminal so
mpv wouldn't redraw so much. There is a gap though. It only assumes
static subtitles. Since ASS can be animated, those types of subtitles
will always need redraws so we need to build in specific detection for
this. We need to build a whitelist of events in ASS that are considered
animations and then flag the packet. Additionally, there's a bunch of
annoying bookkeeping that has to be done since packets can be dropped on
seeks and so on.
This only affects two special cases: printing subtitles to the terminal
and printing subtitles on a still picture. Previously, mpv was very dumb
here and spammed this logic on every single loop. For terminal
subtitles, this isn't as big of a deal, but for the image case this is
pretty bad. The entire VO constantly redrew even when there was no need
to which can be very expensive depending on user settings.
Instead, let's rework sub_read_packets so that it also tells us whether
or not the subtitle packets update in some way in addition to telling us
whether or not to read more. Since we cache all packets thanks to the
previous commit, we can leverage this information to make a guess
whether or not the current subtitle packet is supposed to be visible on
the screen. Because the redraw now only happens when it is needed, the
mp_set_timeout_hack can be removed.
Guido Cella
Dudemanguy
Kacper Michajłow
llyyr
Oneric
nanahi
Misaki Kasumi
Matthias Hunstock
rcombs
sfan5
Christoph Heinrich