| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Found by coverity scan.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Text background refers to the libass-only BorderStyle 4, which is
similar to 3, but isn't affected by outline/border size and doesn't
render shadow, so shadow offset can be used.
You can override the horizontal and vertical box size separately
with override tags, just like you can override the color with
shadow color.
Closes #270
|
| |
|
|
|
| |
Not a serious issue: arguments were named/ordered incorrectly.
No functional change.
|
| |
|
|
| |
Fixes a possible NULL pointer dereference, reported by Coverity.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DirectWrite's FontFileStream does not actually use the data of a specific
font in a collection, which was an expectation of the existing code. It
simply returns a stream to the underlying file, collection or not. So we
need to get the index of the font. This needs to be done lazily as this
information is only available in a FontFace, which is expensive to
initialize.
Add a new optional font provider function for lazy initialization of the
index and use it. This is similar to the check_postscript callback.
Fixes libass#275.
v2: fix type of returned value.
|
| |
|
|
|
|
|
|
|
| |
Avoid that PlayResY is set to 0 when only PlayResX is specified and
set to 1. Setting PlayResY to 0 results in divide-by-zero errors.
Also fix PlayResX calculations in case only PlayResY is specified,
for completeness.
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=1474.
|
| |
|
|
|
|
|
|
| |
We're not aware of any specific reason for this number to be used,
and actual potentially-dangerous cases should be handled by the
other limits.
Fixes #260
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When given a byte c, decode_chars expects that 0 <= c - 33 <= 63,
i. e. that only the six lowest bits of c - 33 are possibly set.
With this assumption, it shifts and adds together multiple c - 33 values.
When c > 96, c - 33 has high nonzero bits, which interferes with other
shifted terms. c < 33 is even worse: c - 33 is negative (if unsigned char
fits in int), and left-shifting negative numbers has undefined behavior.
Even before the shift, on common platforms with a two's complement
representation of negative integers (or if unsigned char does not fit in
int and is promoted to unsigned int), c - 33 has high nonzero bits, which
again interfere with other shifted terms.
To make matters worse, even perfectly valid encoded data is affected when
size % 4 != 0, as decode_font calls decode_chars with '\0', which leads
decode_chars to shift and add -33, causing undefined behavior and/or
incorrect output.
Take our cue from VSFilter and bit-mask c - 33 to keep only the six
relevant bits. To ensure that we get the same bits as VSFilter when
c < 33 and to avoid the undefined behavior of left-shifting negative
numbers, convert the number to unsigned before masking and shifting.
While we are at it, rewrite decode_chars entirely
to get rid of any GPL code from mkvtoolnix.
Related mkvtoolnix bug: https://github.com/mbunkus/mkvtoolnix/issues/1003
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=516.
Also allocate exactly the right amount of memory for the font,
because why not.
|
| |
|
|
| |
Like VSFilter, treat negative values the same as missing values.
|
| |
|
|
|
|
|
|
|
| |
Commit 8c8741fe2000d4b4d89a53f894363a42288cec3e attempted to fix this
expression and make it use the full range of long long, but it missed
the millisecond term.
This fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=522.
The entire timestamp can still overflow long long though.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Handle large and negative values except INT32_MIN like VSFilter.
This avoids both overflow and inconsistent internal state.
This fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=523.
VSFilter handles INT32_MIN like a mix of \an1, \an2 and \an3:
* Vertical alignment is bottom.
* Lines within the event are center-aligned.
* Without \pos or \move, the center of the event is aligned
with the right edge of the screen minus MarginR.
* With \pos or \move, the left edge of the event is aligned
with the position point.
* Without \org, the rotation origin is aligned
with the horizontal center of the event.
* (With \org, the rotation origin is as specified.)
If we wanted to emulate this in libass, the cleanest way would be to
introduce a new horizontal alignment constant for this purpose that
would be used only for ASS style definitions with Alignment INT32_MIN.
This commit makes no attempt to do this and instead arbitrarily picks
\an2 for style definitions with Alignment -INT_MAX-1, which equals
INT32_MIN if int is int32_t. The fact that int is platform-dependent
is one of the reasons for this. We could change Alignment to be int32_t
instead of int for perfect VSFilter compatibility, but the same applies
to many other fields that currently use platform-dependent types.
|
| |
|
|
| |
Oops.
|
| |
|
|
|
|
|
| |
This does not affect functionality in any way,
but it hopefully makes the logic easier to follow.
Resolves CID 175691.
|
| |
|
|
|
|
|
| |
The value used to generate outline cache values is 26.6, so there
is no point in storing the more precise 16.16 in the cache key.
Indeed, this can only reduce the efficiency of the cache
and provide an extra opportunity for overflow.
|
| |
|
|
|
|
|
|
|
| |
border_scale can change, e. g. when ass_render_frame is called twice with
the same renderer but different tracks. Glyphs with equal \bord tag values
but different border_scale values produce different border outlines and
hence should be distinguished in outline cache keys. To this end, store
scaled border widths (which are really used when generating the outlines)
in cache keys instead of \bord tag values.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
has_clips was a workaround for the case where a new image reused
the same memory address as another image used in the previous frame.
In case of such reuse, comparison by pointer address failed
to distinguish the different images in ass_detect_change().
After commit dd06ca30ea79ce50116a43cc5521d4eaf60a017e,
images in the previous frame are no longer freed before
the comparison with current frame. Thus no such reuse can occur,
and the workaround is redundant.
See https://github.com/libass/libass/pull/258.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I noticed that when resizing the mpv window while playback is ongoing
and with subtitles, that subtitles could sometimes get "stuck" on the
screen. The stuck subtitle would remain until the next subtitle event,
or until seeking to a position that has subtitles again.
It turned out that this was a libass change detection bug. The following
steps should reproduce the problem:
1. call ass_render_frame() with a time that has subtitles
2. call ass_set_frame_size() with a different size
3. call ass_render_frame() with a time that has no subtitles
The previous call will return with *detect_change==0.
To make this worse, libass will deallocate image data before the next
ass_render_frame() or ass_renderer_done(), which violates the API and
could possibly make some API users crash. (That the user can rely on
this is not documented though.)
There are two possible solutions:
1. Set a flag in ass_reconfigure(), that makes the next
ass_render_frame() call always return *detect_change==2.
2. Do not discard the previous subtitles (images_root), so change
detection can work reliably.
This commit implements 2. - I prefer this in part because it doesn't
clobber the previously returned image list before the next
ass_render_frame() call. (As pointed out above, this might be unexpected
behavior to the API user.)
This is a regression and was possibly broken by commit dd06ca and later.
I did not check whether it actually behaved sanely before that change,
but it probably did to a degree.
|
| |
|
|
|
|
|
|
| |
ASS_Images returned by libass are guaranteed to be clipped. Not doing
this will cause invalid memory accesses in applications which try to use
this guarantee.
Fixes #254.
|
| |
|
|
|
|
| |
sizeof(ASS_Style) is actually part of the ABI, so adding the Justify field
in commit e54c123d5a08b6212533ddcced2cb1a50fa3d2b2 broke the ABI even
though we tried to avoid it by placing the field at the end of the struct.
|
| | |
|
| |
|
|
|
|
| |
Previously was possible to set only bitmap_max_size,
now requested memory amount is divided between
bitmap_max_size and composite_max_size.
|
| |
|
|
|
| |
Discovered by OSS-Fuzz.
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=229.
|
| |
|
|
|
| |
This did not cause any problems, but it's nicer
to guarantee that the return value is <= end.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When parse_tag is invoked recursively to handle the animated tags inside
a \t tag, the `end` argument is taken from the `end` field of a struct arg
in the enclosing parse_tag. When struct arg is filled by push_arg, this
field is always right-trimmed using rskip_spaces. Ultimately, the inner
parse_tag invokation sees its `end` argument point not to the ')' or '}'
of the \t as it expects but rather to the spaces preceding the ')' or '}'.
At this point, when parse_tag calls skip_spaces, which is ignorant of the
end pointer, it happily skips over the spaces preceding the ')', moving the
pointer past `end`. Subsequent `pointer != end` comparisons in parse_tag
fail (as in fact `pointer > end`), and parse_tag thinks it is still inside
the substring to be parsed.
This is harmless in many cases, but given either of the following inputs,
parse_tag reads past the end of the actual buffer that stores the string:
{\t(\ }
{\t(\ )(}
After this commit, parse_tag knows that `end` can point to a sequence of
spaces and avoids calling skip_spaces on `end`, thus avoiding the overread.
Discovered by OSS-Fuzz.
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=194.
|
| |
|
|
|
|
|
| |
MinGW and old versions of mingw-w64 don't define the SAL macros.
They don't serve any value to us, so just remove them from our code.
See https://github.com/libass/libass/pull/251.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Avoid overflow in dblExp that prevents subnormal numbers from being
generated (or small normal numbers if `double` supports many more
negative exponents than positive): if `10**abs(exp)` would overflow
and we actually want a negative exponent, switch to using precomputed
negative powers of 10 rather than positive.
Also avoid underflow for numbers with a large negative exponent where
the exponent alone underflows but the significand has enough digits to
cancel this out, e. g. in `10e-324` with IEEE 754 double.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The exponent may overflow an integer, e. g. in
`14e888888888888888888888888888880000000000000000000000000000`
on a 32-bit platform. Correctly handle this, including the case
when the exponent overflows but the whole string still describes
a valid floating-point number, e. g. in
`1[4294967200 zeros]e-4294967300`.
This fixes libass#244. Buffer overflow was fixed in 67f647e, and
this ensures that the string is converted to the correct number.
|
| |
|
|
|
|
|
|
| |
ass_strtod reads at most 18 leading digits of the mantissa.
This previously included zeros, even though they are not significant
digits, e. g. 0.000000000000000001e18 was converted to 0.0.
After this commit, leading zeros before and after the decimal point
will be skipped, so the above number will be correctly converted to 1.0.
|
| | |
|
| |
|
|
|
| |
This fixes overflow on extremely long input strings.
See libass#244.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Subtitle recommendations often include that multi line
subtitles should be left justified as this is easier for
the eyes. This is also the standard used by several television
companies.
This add the possibility to define how subtitles are to
be justified, independently of where they are aligned.
The most common way could be to set justify to left, and have
alignment to center. But you can, for example, have alignment
to left and justify to center, giving subtitles to the left but
justifed on the center (instead of normal left justified).
Using justify right and alignment of center, might be good
choice for Arabic.
If justify is not defined, all works like before.
If justify is defined, subtitles are aligned as defined
by alignment and justified as defined by justify.
ASS is not extended by this, justify can only be defined
by setting Justify to wanted justification.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes two separate bugs:
a) Don't move a linebreak into the first symbol. This results in a empty
line at the front, which does not help to equalize line lengths at all.
Instead, merge line with the second one.
b) When moving a linebreak into a symbol that already is a break, the
number of lines must be decremented. Otherwise, uninitialized memory
is possibly used for later layout operations.
Found by fuzzer test case
id:000085,sig:11,src:003377+003350,op:splice,rep:8.
This might also affect and hopefully fix libass#229.
v2: change semantics according to review
|
| |
|
|
|
| |
Found by fuzzer test case id:000082,sig:11,src:002579,op:havoc,rep:8.
Correctness should be checked, but this fixes the overflow for good.
|
| |
|
|
| |
Found by fuzzer test case id:000051,sig:11,sync:fuzzer3,src:004221.
|
| |
|
|
|
|
|
|
| |
Update the variable that tracks the allocated size. This potentially
improves performance and avoid some side effects, which lead to
undefined behavior in some cases.
Fixes fuzzer test case id:000051,sig:11,sync:fuzzer3,src:004221.
|
| | |
|
| |
|
|
| |
This can improve perf somewhat with large bitmaps
|
| | |
|
| |
|
|
|
|
|
|
| |
This is a normal course of action and should not generate a warning,
especially for applications which use libass and might notify the user
on such "warnings", while in fact it should be info or even verbose.
Fixes #231
|
| | |
|
| | |
|
| |
|
|
|
| |
That resources can be cached composite bitmap or raw bitmap buffer.
Consequently, free lists are no longer needed.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Advantages over the old algorithm consist of the following.
* There are no glitches due to full cache clearing.
Items are arranged into linked list ordered by time of last use.
Only the oldest items get deleted at the clearing event.
* Each item now keeps track of number of references.
Referenced cache values are immune to clearing.
* Reduced amount of total cache memory for the same performance.
* Reduced number of memory allocations per cache item.
|
| |
|
|
|
|
|
|
| |
VSFilter uses LTR base direction even if Arabic or Hebrew font
encodings are used, so do the same. This resolves some reordering
issues.
Fixes #224.
|
| | |
|
| |
|
|
|
|
|
| |
Such points can overflow internal calculations and usually produced
as a result of NaN to integer conversion.
Should fix #210.
|
