| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
This reverts commit 6c2120a7cb4a6fd648ef37ad8f0d961cbd60f500.
This turned out never to actually be necessary, wasn't actually consistent
with vsfilter, and could result in script authors relying on
accidentally-introduced deviations from vsfilter font matching.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Providing a negative acceleration to \t could result in undefined behavior due
to overflow in float->int conversion. This codifies the same behavior we
currently have on x86, which matches vsfilter's, without actually invoking UB.
Additionally, vsfilter color animations work subtly differently than ours did.
We used to lerp each individual color component's byte value, while vsfilter
performs the lerp on the component _in place within a larger int_. This didn't
result in major issues for most cases, but could probably result in subtle
rounding errors, and gave vastly different results for \t with negative
acceleration.
Negative \t acceleration is probably completely useless, but our behavior was
wacky in a different way from vsfilter's, and I'd rather have portable
wackiness than libass-specific wackiness.
It might still be possible to invoke UB in negative-acceleration \t using tags
other than colors; we should fix those cases as well.
|
|
|
|
|
| |
This provides higher precision in reported weights when using
the fontconfig font provider.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The assertion in commit 66cef6774386d558e1e39096db926d677dad6882
fires on the following ASS code:
\t(\t(foobar,)
(where "foobar" is any nonblank sequence that does not contain a backslash)
The outer \t is parsed as having a single argument "\t(foobar,"
including the comma. The inner \t is parsed as having a single
argument "foobar" *excluding* the comma. As a result, in the inner
parse_tags, args[cnt].end == end - 1 && nested, and the assert fires.
This is because arguments that contain backslashes are parsed
differently from arguments that do not. But if the argument to \t
contains no backslashes, why bother parsing it at all?
It clearly has no override tags and affects nothing.
Rather than try to make the assert more clever (and more convoluted),
this commit skips parsing the last \t argument if it has no backslash.
The assert is now valid. This probably does not significantly affect
parsing speed in either direction.
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=25796.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before commit 6835731c2fe4164a0c50bc91d12c43b2a2b4e799,
parse_tags used to recurse for each nested \t(). The depth
of this recursion was not limited, and each \t in \t(\t(\t(...
added another level. This could lead to stack overflow.
Since that commit, parse_tags still recurses, but at most once:
it is called with nested=false at the top level and recurses with
nested=true for the outermost \t() (except rare cases in which
even this one level of recursion is avoided). Parsing stops at
the closing ) both for the outermost \t() and for any inner \t()
nested inside it, so the inner recursive call cannot recurse further.
This was not immediately obvious when reading the code,
and therefore it was not obvious that stack overflow is avoided.
Make it so by adding an assertion.
|
|
|
|
| |
GCC, Clang and MSVC now issue a warning when deprecated API is used.
|
|
|
|
|
| |
Also makes a measurable difference on float-parse-heavy scripts,
and it's not like these had a reason to not be in the header.
|
|
|
|
|
|
|
|
|
|
| |
Yes, this actually makes a major difference on some tag-heavy scripts.
This lets the whole function get inlined, rather than making a call out
to the libc's strcmp implementation. The libc's version is likely
much faster on longer strings, but we're only ever comparing against
strings that are a few characters long, so that doesn't really matter.
It also avoids making an extra pass for the strlen.
|
|
|
|
|
|
|
| |
Some releases rely on this.
See corresponding VSFilter code:
https://github.com/Cyberbeing/xy-VSFilter/blob/cf8f5b27de77fe649341bfab0fdfd498e1ad2fa6/src/subtitles/RTS.cpp#L1270
https://github.com/Cyberbeing/xy-VSFilter/blob/cf8f5b27de77fe649341bfab0fdfd498e1ad2fa6/src/subtitles/RTS.cpp#L1291
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bracket matching is incompatible with VSFilter (even on modern
Windows), so disable it by default. But as it's generally
a good thing (and 100% more compliant with current Unicode),
keep it available as an ASS_Feature.
It can be toggled individually or enabled as part of the
catch-all ASS_FEATURE_INCOMPATIBLE_EXTENSIONS feature.
If libass is compiled against FriBidi older than 1.0,
bracket matching is impossible. Signal this at runtime
by failing to recognize the ASS_FEATURE_BIDI_BRACKETS
feature. This way, clients who want to use bracket matching
can set the feature without any compile-time checks for
FriBidi and can be freely linked against libass that is itself
compiled against any version of FriBidi; and yet they can
detect at runtime whether the feature is actually enabled.
Fixes https://github.com/libass/libass/issues/374.
|
| |
|
| |
|
|
|
|
|
|
| |
The only prealloc value actually used is 0, which is not useful
and invokes implementation-defined (and potentially obsolescent
as per C11 DR400) behavior.
|
|
|
|
|
|
| |
This more forgiving behaviour resembles VSFilter's more closely and will
fix #117 ; trailing whitespace should not be an issue.
Though as pointed out in #19 VSFilter is still far more lenient.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes https://github.com/libass/libass/issues/141.
Fixes https://github.com/libass/libass/issues/300.
VSFilter's original intention with this seems to have been to transform the
event as a whole, including the shadows as an integral part, as opposed to
transforming the shadows separately: imagine the event being rasterized into
a single image including the shadows, and then that image being transformed.
Unfortunately, due to a caching bug, what actually ends up happening is that
the shadow is transformed the intended way, but the main body is then simply
shifted back by \shad from the transformed & rasterized shadow, instead of
being transformed & rasterized on its own. The result seems sensible if you
look at the shadow only but incomprehensible if you look at the main body.
Transforms with \shad are actually used and this behavior is relied upon,
as evidenced by https://github.com/libass/libass/issues/300 (in which
the main body is made invisible and the shadow is used instead of it
due to having \t-animatable position and full-area blur despite \bord).
|
|
|
|
| |
This is *VSFilter compatible and fixes #287.
|
|
|
|
|
|
|
| |
ffmpeg/libav did rely on *VSFilter incompatible libass defaults for years.
Avoid breaking them when changing libass' default to match *VSFilter.
To this end detection of the generated by ffmpeg signature is added.
|
|
|
|
|
|
|
|
| |
Keeps backwards compatibility as libass is currently the only renderer accepting
custom format lines and is currently defaulting SBAS to 'yes' (VSF incompatible)
This commit also changes the default/fallback ASS Event format to use 'Name'
instead of 'Actor'.
|
|
|
|
| |
And warn about duplicate headers
|
|
|
|
|
|
|
|
| |
closes #304
With this commit the padding of the BorderStyle=4 box, given by \shad, is no
longer measured from the text without borders, but from the border of the text.
(Alternative description: padding changed from \shad to \shad+\bord)
|
| |
|
|
|
|
|
|
| |
closes #143
As libass doesn't support the 'Collsions' header, we are only concerned with the
default stacking direction of *VSF here
|
| |
|
|
|
|
|
|
|
| |
- Convert tabs to spaces
- Ensure one space between keywords and parenthesis
- Ensure space between ')' and '{'
- Trim trailing whitespace
|
| |
|
| |
|
|
|
|
|
| |
We used to do a lot of work to get freetype to imitate VSFilter's font-metrics
handling. Instead, we now just duplicate its behavior directly early on.
|
|
|
|
| |
device_x is in anamorphic coordinates, the product of x2scr (not x2scr_scaled).
|
|
|
|
|
|
| |
The ratio was accidentally flipped.
Use the actual video size, not the screen size that includes margins.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Based on a commit by wm4.
Nowadays, margins are used by players such as mpv to implement
video zoom & pan, although this was not expected when margins
were first implemented in libass. This results in unpleasant
rendering when panning too far, and it is argued that subtitles
should not change size or move when panning and zooming at all.
libass also makes an attempt to keep subtitles on screen even when
the use of margins is disabled. This is unintuitive and prone to break.
Fix this by strictly separating events which render as if they were
part of the video, and events which should use margins. The latter
will now use the entire screen as canvas, rather than using the video
frame. This actually simplifies the various y2scr functions.
To preserve scaling (mainly for styled subtitles where line breaks are
carefully chosen based on font/video size ratio) and to avoid badly
stretching out things like ASS Margins due to aspect ratio differences
between video and screen, estimate the unpanned & unzoomed video size
from the video aspect ratio and the screen size, and base all scaling
on that. This means that if the user plays a video in letterboxed mode
without extra margins, they get the same scaling as if they were playing
the same video with the same video rectangle size without any margins
at all (with some elements merely spaced out to make use of the black
bars); and when they zoom & pan afterwards, the subtitles don't move
or change size.
This changes behavior even with ass_set_use_margins(_, 0). Before this,
normal dialogue was forced into the visible video area (if negative
margins were set); now it renders it as if it were part of the video.
This also changes the behavior of left and right margins even with
ass_set_use_margins(_, 1). Before this, normal dialogue was forced
into the visible video width (with both positive and negative margins);
now it renders across the entire width of the screen/window.
For 4:3 video letterboxed on 16:9 screen, this means text will cross
the edges of the video, which may look worse than before.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Normal subtitles in use_margins mode, which do not have \clip tags or
similar, were clipped in a nonsensical way. It was especially visible
when moving subtitles up with ass_set_line_position().
This happened because state.clip_* is initialized with a clipping
rectangle for the video area. Later it tries to translate the clipping
rect accordingly, but this does not make much sense if you account for
the margins.
Just reset the clipping rect to the screen in these cases. explicit=0 is
enough to know that the clipping rect was never explicitly set.
|
| |
|
|
|
|
| |
Closes #397
|
|
|
|
|
|
|
|
| |
The while() checked the pointer for nullness, so the analyzer assumed it could
potentially be null, and thus warned on the reference to it later.
Using a do/while instead means we're only checking for subsequent linked-list
entries, which was the intent here anyway, and avoids the warning.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Since C does not allow empty enums, there is an "example", which doesn't
do anything. I think we might be able to make this change the default
bidi direction or so. As if this commit, the flag set by it is also not
available outside of ass.c, which should be solved by moving parser_priv
to an internal header.
|
|
|
|
|
|
|
|
| |
This just gives a minor hint that all fields are frozen, but that the
size of the structs are not part of the ABI.
Most importantly, ASS_Style and ASS_Event are completely ABI-frozen,
because ASS_Track has the "styles" and "events" arrays.
|
|
|
|
|
|
|
|
|
| |
Check for overflows that could happen with alignment and the
multiplication. The INT_MAX / 4 is somewhat approximate and assumes that
degenerate alignment values won't happen.
This still assumes that a possibly overflowing end_w/end_h calculation
doesn't make the compiler's optimizer destroy the overflow checks.
|
| |
|
| |
|
|
|
|
|
| |
This makes it a bit clearer that the struct's contents won't be reused
across multiple iterations
|
|
|
|
| |
This fixes a double-free in be0d1613f79a95073d18d96a60e1394abf9316a2
|
|
|
|
|
| |
This previously gave the pre-transition value; VSFilter's behavior is to give
the post-transition value.
|
|
|
|
|
|
|
|
| |
Fixes a crash in case a font does not has kCTFontURLAttribute,
which is the case for example on macOS 10.15.1 for the
".AppleSymbolsFB" font.
Fix #358
|
|
|
|
|
| |
This makes results much more consistent with other platforms,
particularly around cases where fonts have multiple conflicting names.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Use FcWeightToOpenType when available; otherwise, use an if/elseif ladder
implementing the inverse of fontconfig's behavior.
|
| |
|
|
|
|
|
|
| |
And conversely, do faux-bold fonts that are too thin
The offset of 150 matches VSFilter's behavior
|
| |
|
|
|
|
|
|
|
| |
Some fonts have weights that can be expressed more precisely as doubles than
as floats. In these cases, when writing to a float, CFNumberGetValue will set
the value to the closest approximation, but return false (so we'd just clobber
whatever it set with 0). Easy fix: just store to a double instead.
|
|
|
|
|
|
|
|
|
| |
shift_event() can change "bitmap" field of ASS_Image struct
so direct deallocation is no longer possible.
This commit introduces additional field "buffer"
into ASS_ImagePriv for that purpose.
Fixes https://github.com/libass/libass/issues/310.
|
|
|
|
| |
This allows making use of the updated UBA in Unicode 6.3 and up.
|
|
|
|
| |
Fix documentation misspellings/texts.
As reported by Clang.
|
|
|
|
| |
Found by Coverity Scan and -fsanitize=undefined
|
|
|
|
|
|
|
|
|
|
|
|
| |
Slow movement of one glyph looks like periodic jumps by quantization step.
In case of multiple glyphs at different subpixel shifts
jumps of individual glyphs occur at different frames.
That leads to performance penalty due to composite image
regeneration at every such jump.
This commit aligns glyphs in such a way that all jumps coincide
at the same frames, greatly improving performance of \move commands.
That optimization also helps in case of fast motion.
|
|
|
|
| |
Fixes https://github.com/libass/libass/pull/321.
|
| |
|
|
|
|
|
|
|
|
|
| |
This also potentially improves performance by copying
and transforming in a single operation rather than
copying first and then transforming the result.
Also transformation function is specialized for case
where expensive perspective division is not necessary.
|