| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
Found by Coverity Scan.
Fixes CID 303760.
Fixes CID 303761.
|
|
|
|
|
| |
ass_msg's callback will most likely use vprintf. Passing NULL as %s to
a _printf function is undefined behaviour.
|
|
|
|
|
|
|
| |
We can't parse the style without a valid style_format.
If strdup for FontName or Name or there fallback values fails,
the style is of no use, so discard it. As the removal happens before any
other styles are added, just decreasing n_styles is safe here.
|
|
|
|
|
|
|
|
|
| |
strdup failures for event->Text and event->Effect are already guarded
against in ass_render.c and ass_parse.c.
event->Name is never used, thus also safe.
At this point event_format is guaranteed to be valid, so it doesn't
need to be checked.
|
|
|
|
|
| |
In case of strdup-failure track->event_format can be assigned NULL in
event_format_fallback or in process_events_line
|
|
|
|
|
|
|
|
|
|
|
| |
Strictly speaking this is not neccessary in regular processing as the
event and font fields are intialised with zeroes anyway and there's no
old value to fallback too.
However when processing style overrides, this can prevent a non-null
value being replaced by NULL.
This commit also gets rid of the unneccessary '!= NULL' check. Passing
NULL to free is well defined and safe.
|
|
|
|
|
|
|
|
| |
This way we can ensure that there's always one style in the track (which
some parts of the code already assume) and that this style is actually
valid.
If the style alloc fails, the whole track alloc will fail and we're
likely seriously short on memory anyway
|
|
|
|
|
|
|
|
|
|
| |
In case of files whose size is close to or exceeds SIZE_MAX it was
possible to trigger an overflow while calculating new_size.
Although ASS_REALLOC_ARRAY already deals with the most problematic case
of an overflow yielding new_size == 0, continuing will only yield
garbage fontdata at the end, so we might as well abort right away.
Unrelated: correct return code for mangled lines
|
|
|
|
|
|
|
|
|
|
|
|
| |
size_t is a more sensible type for as it is unsigned and accurately
represents the theoretical limits of object size. int may be larger or
smaller than size_t, which both would lead to problems and potential UB
with signed overflow.
There was no usage of negative values as error flags or similar and
those two fields are not part of the public API, so this change should
be safe.
To stay consistent, also adjust types of related variables in functions.
|
| |
|
| |
|
|
|
|
|
|
| |
Also deal with potential overflows of style and event count.
Since these fields are ints part ofthe public API, but will be cast to
size_t in ASS_REALLOC_ARRAY use the smaller of both limits.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is incompatible with VSFilter, so maybe we
should later change this to use uint32_t instead.
This fixes the multiply-divide if the result fits in int,
but `PlayResX = PlayResY * 4LL / 3;` still overflows if PlayResY
is close to INT_MAX. This should be addressed in a separate commit.
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=533.
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=603.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
- Convert tabs to spaces
- Ensure one space between keywords and parenthesis
- Ensure space between ')' and '{'
- Trim trailing whitespace
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Found by Coverity Scan and -fsanitize=undefined
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Discovered by OSS-Fuzz.
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=229.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Found by fuzzer test case id:000051,sig:11,sync:fuzzer3,src:004221.
|
|
|
|
| |
Finds the start of the subtitle at "now".
|
|
|
|
|
|
|
|
| |
Not all API users will keep the event list on seeking. This also gives
the opportunity to API users to handle severely broken files with
duplicate ReadOrder entries. (It is not known whether this is really
needed, however VSFilter does not deduplicate using the ReadOrder
field.)
|
|
|
|
|
| |
Otherwise, ass_process_chunk() will reject events that were previously
removed with ass_flush_events(), which is nonsense.
|
|
|
|
|
| |
Keep all components signed, allowing for timestamps like 00:01:-05.00
to denote 55 seconds. This matches the behavior of VSFilter.
|
|
|
|
| |
Reported by gcc -Wall -Wextra.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The loop in check_duplicate_event() essentially makes event processing
with ass_process_chunk() O(n^2). Using a bitmap instead of a loop brings
it back to O(n).
This could be interpreted as an API change: since the event list is
freely modifieable by the API user through ASS_Track public fields,
libass can't know if the internal bitmap went out of sync with the
public event list. We just redefine it so that calling
ass_process_chunk() means the API user agrees not to manipulate the
event list otherwise.
|
|
|
|
|
|
|
|
|
|
|
| |
There is no real value in it. ENCA only works in some cases and I
can't find any information about software that integrates libass
which relies on it or users that rely on ENCA support in case the
interface is exposed directly (e.g. in MPlayer).
If there is still a wish to have charset detection integrated into
libass (it is out of scope, IMHO), a better library like uchardet
should be used for that.
|
|
|
|
|
|
|
|
|
| |
As before, this does not add any build system support:
a config.h file and a project must still be manually created
(or the compiler can be run manually instead of using a project).
Signed-off-by: Grigori Goronzy <greg@kinoho.net>
Signed-off-by: Oleg Oshmyan <chortos@inbox.lv>
|
| |
|
|
|
|
|
|
|
|
| |
OS or platform-specific locale independent functions are painful to
use and/or not available, so roll our own. Not great but the least
painful and least intrusive.
v2: fix indexing, use static inline
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ass_set_fonts_dir() is supposed to enable all fonts in a specific
directory. The implementation for it was dropped with the commit
introducing the new fontselect code. Some users were relying on it, so
we need it back.
It used to be implemented using a single fontconfig call. But since this
has to work even if fontconfig support is not even compiled, a new
implementation is needed.
This commit adds very simple and low-effort support for it. It loads all
files into memory, and then lets the memory font code do the rest. A
more efficient implementation would be possible, for example by
implementing a new font provider, which serves get_data requests from
open file handles. Anyone who wants to do this is welcome to try, and
this commit is just the minimum to restore the lost feature.
|
|
|
|
|
|
|
|
|
| |
The timecode is a long long, but it is computed as a product whose
all multiplicands are (unsigned) ints and so effectively has the value
of an (unsigned) int. Fix this, and use the full long long range,
by explicitly making one of the first two multiplicands a long long.
Found by Coverity Scan.
|
|
|
|
| |
Reported by clang scan-build static analysis.
|
|
|
|
|
| |
Reported by clang scan-build static analysis. Also fix incorrect
return value in case of error.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Allow exactly one of these prefixes in header values:
0x, 0X, &h, &H. Note that "0x0xFFFFFF" is a correct value,
as the first 0x is consumed by the parser and the second by
the string-to-number conversion following strtol semantics.
* Allow arbitrary numbers of leading & and H
(and not h) in any order in override tag values.
* Reduce header values modulo 2**32 instead
of saturating them to LLONG_MIN/MAX.
* Saturate override tag values to INT32_MIN/MAX
rather than to LLONG_MIN/MAX.
* Don't fiddle with bytes in alpha override tag values.
(They can be outside of the 0..255 range.)
Also change the byte swapping code to be more sensible.
Fixes #80.
Fixes #145.
Fixes #178.
Also fixes our behavior in the case described in
https://code.google.com/p/xy-vsfilter/issues/detail?id=80.
|
|
|
|
|
|
|
| |
Fixes "[ARR] Musashi no Ken - 01 [AVC][5697986B].ssa", which has
timestamps like "00:02:30.85". It starts with 2 zeros instead of one,
which probably means it's an invalid file, but it's accepted by various
other parsers (VSFilter, MPlayer, vlc, ffmpeg).
|
|
|
|
|
|
|
|
|
|
| |
This was a check for the realloc() call, but the result was never
used in the success case - which makes no sense.
Doesn't really matter, because it's the legacy charset code which
hopefully is not used by anyone.
Found by Coverity.
|
|
|
|
|
|
|
|
|
|
| |
Use strndup() instead of malloc+copy.
Make all code deal with the possibility that ASS_Drawing.text can be
NULL (which can happen on allocation failure).
Skip fix_collisions() on malloc failure - the lines will overlap, but at
least libass won't crash.
|
|
|
|
| |
This is just a start and gets most easy ones.
|
| |
|
|
|
|
|
| |
Also replace strtocolor in ass_utils with string2color
from ass.c, because that is more useful everywhere now.
|
| |
|
|
|
|
|
|
|
| |
These aren't very useful for debugging due to the high volume of the log
output in problem cases. In fact, all they do is making the code slower
(the message callback can easily appear in the profiler output, even if
the callback doesn't actually print the messages).
|
|
|
|
| |
This reduces the frequency of reallocations.
|
|
|
|
| |
Obtained by reading the xy-VSFilter source code.
|
|
|
|
| |
This complements 5903771e.
|
|
|
|
| |
The "if (0) { // cool ;)" is just mindblowing.
|