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.
Previously, mpv only saved a strict limit of two packets while decoding
subtitles, but it is a bit incomplete. Firstly, it's certainly possible
for there to be more than two subtitles visible at once. And also, it
did not take into account preloading. Rework this mechanism so that it
is a growable array that can store as many packets as we want. Note that
in this commit, the packets are only ever discarded on reset or destroy,
so in theory it could grow forever. Some discarding logic will be added
in the next commit since it is inherently tied to other things.
* Range of accepted values for teletext_page now include 0 and -1.
* 0 means "subtitle" and -1 means "*".
* Make 0 the default.
Signed-off-by: Mohammad AlSaleh <CE.Mohammad.AlSaleh@gmail.com>
Before 3250f6e447, secondary subtitles
didn't work properly with sd_lavc at all. They would render but be in
the same position as the primary subtitles. sd_ass used SD_CTRL_SET_TOP
to specifically place secondary subtitles in a different spot, but it
was unused by sd_lavc. With that above mentioned commit, it became
possible to distinguish between the position of primary and secondary
subtitles via mpv's option system. sd_lavc was missed however because at
the time we simply didn't realize this could work and was actually
simple. With some subsequent refactoring that happened later, the fix is
to just use the correct sd->order when accessing the shared subtitle
options instead of hard coding 0. Fixes#13440.
f9cefbfec4 made it so mp_ass_flush_old_events() is continously called on
subtitles with unknown duration, without explaining why, breaking
sub-seek/step -1 with a VO (the issue does not occur when showing
subtitles in the terminal because get_bitmaps() is not called). I don't
experience any issue after removing the call, so delete it to fix these
commands.
After removing that, you can sub-seek -1 once after regular playback,
but not after seeking and thus not multiple times in a row. This is
caused by a714f8e928 which fixed subtitles with unknown duration being
duplicated when seeking with a VO (it does not happen in the terminal)
by clearing old lines on seeks, which broke sub-seek -1 and sub-step -1
in a second way after any seek. The proper fix is to remove the line
ctx->num_seen_packets = 0 for subtitles with unknown duration instead,
which lets decode() return early when a line has already been shown.
Having removed these 2 lines, I also removed sd->preload_ok = false, and
thus the whole conditional, since according to sub/sd.h preload_ok only
needs to be set to false when old subtitles are discarded, and they are
no longer discarded,
The bug can be reproduced with
mpv --sub-file=<(curl 'https://music.xianqiao.wang/neteaseapiv2/lyric?id=1399616170' | jq -r .lrc.lyric) 'https://www.youtube.com/watch?v=dQw4w9WgXcQ'
strlen is only relevant if the length is less than [1, 4], so this can
be replaced with strnlen instead which will only traverse characters
upto the maxlen insted of the entire string length. It also makes MPMIN
unneeded. Also fix a comment.
The +1 here is not correct. For a 4-byte unicode character, this would
throw a runtime error because the +1 would try to assign the null
terminator past the actual bound of our array. Just remove it since it
should be exactly equal to whatever we have for bytes.
There's a simple check in filter_sdh that gets the bytes of the first
character in a string in order to do pointer arthimetic to filter the
string. The problem is that it is possible for the amount of bytes to be
greater than the actual length of the string for certain unicode
characters. This can't be worked with so enforce the strlen as the
absolute minimum here to avoid overflow situations.
Fixes#13237.
Missed in 3250f6e447. Note that the
hardcoded ass alignment value is not used anymore as of that commit, but
we should ideally be moving towards secondary subs actually being
customizable via ASS anyways.
