summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Release 0.15.00.15.0Oleg Oshmyan2020-10-275-6/+46
|
* Add missing file to MakefileOleg Oshmyan2020-10-271-1/+1
|
* Work around broken Travis CI macOS buildOleg Oshmyan2020-10-271-0/+1
| | | | | | Sigh. The Homebrew addon is broken with update: false (the default!). It has been fixed for osx_image: xcode11 and newer, but the default image is older.
* Fix \kf speed in anamorphic videoOleg Oshmyan2020-10-271-1/+2
|
* Speed up macOS Travis CI buildsOleg Oshmyan2020-10-271-1/+1
| | | | | | | | | Updating Homebrew takes more than 5 minutes. Upgrading other things that depend on FreeType takes more than 6 minutes. Together, that's 11+ minutes of build time gone to waste. It seems Homebrew in the current default osx image has all the dependencies we need without needing to update.
* Fix two freshly introduced memory leaks upon alloc failureOleg Oshmyan2020-10-271-7/+10
| | | | | | | Found by Coverity Scan. Fixes CID 303760. Fixes CID 303761.
* process_karaoke_effects: honor info->skip in \kf calculationsOleg Oshmyan2020-10-271-2/+8
| | | | This mainly affects trimmed trailing whitespace.
* Improve \kf position roundingOleg Oshmyan2020-10-273-9/+9
|
* Fix shifted \kf position with rectangular \iclipOleg Oshmyan2020-10-271-0/+1
|
* Fix \kf fill positioningOleg Oshmyan2020-10-274-6/+41
| | | | | | | | | | | | | | | | | | Our effect_timing is currently used as a coordinate relative to a weird origin: take each glyph's center within the run, apply 3D transforms, pick the leftmost one, and round it down a little. This makes no sense and is the result of an unrelated code change. But if I recall correctly, \kf positioning was already incorrect before that last change (but in a different manner). To fix this and hopefully to prevent this kind of error from occurring again, convert effect_timing to absolute screen coordinate. Start the fill at the glyph run's leftmost post-transform control point. This matches VSFilter and allows karaoke to work in vertical text (unlike, for example, starting the fill at the first glyph's pre-transform origin). Fixes https://github.com/libass/libass/issues/216. Fixes https://github.com/libass/libass/issues/357.
* process_karaoke_effects: fill from right to left if rotatedOleg Oshmyan2020-10-271-0/+10
| | | | This matches VSFilter.
* Delay angle conversion to radians until the last momentOleg Oshmyan2020-10-272-8/+9
| | | | | This allows decisions based on the angle values to be slightly more accurate and might save us a few flops.
* Handle \k0 \ko0 \kf0 \K0 like VSFilterOleg Oshmyan2020-10-272-4/+16
| | | | | | | | | | | | | Don't break runs when zero-duration karaoke starts unless the karaoke *type* differs. The zero-duration karaoke block ends up glued to the previous block (if any). In case of subsequent karaoke override tags, like {\k100\k0}, the intervening tags will advance the next karaoke block's start time, but not this combined block's start or end time. Of course, runs may still be broken in the same place if there's another reason for a run break besides karaoke, so zero-duration karaoke blocks can still occur. Run breaks that have no karaoke tags at all also still produce zero-duration karaoke blocks (if there is karaoke at all).
* process_karaoke_effects: use long long for timestampsOleg Oshmyan2020-10-271-3/+3
| | | | | | | | Our frame timestamps are long long. Don't truncate them to int here. This also avoids overflow in (tm_end - tm_start) if \k... tag arguments are big, although, of course, parse_tags still reads them in as doubles to begin with and their conversion from double may still be undefined.
* process_karaoke_effects: compute \kf from glyph advances, not boundsOleg Oshmyan2020-10-271-6/+2
| | | | Both ways make sense, but traditional VSFilter does it this way.
* Drop the now-useless, previously-broken first_pos_xOleg Oshmyan2020-10-272-5/+2
|
* process_karaoke_effects: place line at infinity except during \kfOleg Oshmyan2020-10-271-9/+8
| | | | Fixes \k and \ko in https://github.com/libass/libass/issues/357.
* process_karaoke_effects: reuse \kf logic for \k and \koOleg Oshmyan2020-10-271-15/+10
|
* process_karaoke_effects: explicitly handle edge cases for \kfOleg Oshmyan2020-10-271-2/+8
| | | | | | | In particular, don't divide by zero given \kf0. This fixes https://github.com/libass/libass/issues/124. The order is important: \kf accepts negative values.
* process_karaoke_effects: honor starts_new_runOleg Oshmyan2020-10-272-7/+13
| | | | | | | | | | | This matches VSFilter. In particular, compared to what we did before, karaoke blocks additionally end when an override tag changes something, as well as on any line break (after the trimmed leading whitespace on the new line) and after any trimmed leading whitespace on the first line. The text that follows the break has a zero karaoke duration, and its karaoke effect starts immediately after the karaoke effect ends for the block before the break.
* process_karaoke_effects: give the code a facelistOleg Oshmyan2020-10-271-50/+38
|
* Remove unused rot_key functionOleg Oshmyan2020-10-271-6/+0
| | | | Unused since commit c80f332798238731e1ddf1b541748f3d5c8030f3.
* Avoid passing NULL as a %s parameterOneric2020-10-271-1/+7
| | | | | ass_msg's callback will most likely use vprintf. Passing NULL as %s to a _printf function is undefined behaviour.
* Handle strdup-fails regardinging FontFamilyOneric2020-10-272-9/+19
| | | | | | | We already ensure at creation that all styles have a non-null FontName. However font family strings are strduped at various places and NULLs cannot be fully avoided, since already the very first font strdup may fail, so additional checks are required.
* Check for strdup_failures in process_styleOneric2020-10-271-3/+12
| | | | | | | 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.
* Check for strdup failures in process_event_tailOneric2020-10-271-3/+5
| | | | | | | | | 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.
* Ensure track->event_format is valid before parsingOneric2020-10-271-4/+7
| | | | | In case of strdup-failure track->event_format can be assigned NULL in event_format_fallback or in process_events_line
* Make STRVAL macros strdup-fail safeOneric2020-10-271-4/+10
| | | | | | | | | | | 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.
* Allocate and set default style directly at track creationOneric2020-10-271-21/+20
| | | | | | | | 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
* Handle realloc fail in process_fonts_lineOneric2020-10-271-13/+26
| | | | | | | | | | 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
* parser_priv: Change type of fontdata_{size,used} to size_tOneric2020-10-272-7/+7
| | | | | | | | | | | | 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.
* ass.c: handle style alloc failureOneric2020-10-271-2/+5
|
* ass.c: handle event alloc failsOneric2020-10-271-0/+4
|
* API: make ass_alloc_{style,event} alloc-fail safeOneric2020-10-272-14/+16
| | | | | | 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.
* Handle track alloc failure in parse_memory safelyOneric2020-10-271-0/+2
|
* doc: clarify docs regarding track creation and freeingOneric2020-10-272-4/+7
|
* coretext: return full/PostScript name on fallbackOleg Oshmyan2020-10-231-9/+16
| | | | | | | | | CoreText's "family name" can use TT_NAME_ID_TYPOGRAPHIC_FAMILY names, which we ignore for compatibility with VSFilter. As a result, fallback returns a family name that we then fail to find, and fallback fails. Return a fuller name (fullname or postscriptname as appropriate) instead, which should be more reliable.
* ass_render: Replace Segment with RectOneric2020-10-222-39/+34
| | | | | | | | | Contrary to what the comments suggest Segment does not use one absolute reference point and relative offsets, but two absolute points, making it practically identical to the previously defined Rect with a <-> y0, b <-> y1, ha <-> x0, hb <-> x1 For simplicity replace Segment with Rect.
* ass_shaper: remove dependency on hb-ftrcombs2020-10-221-3/+40
|
* ass_shaper: handle harfbuzz allocation failuresrcombs2020-10-221-14/+22
| | | | | | | | | Edit by Oleg Oshmyan <chortos@inbox.lv>: Move the final ass_shaper_shape returns inside the switch. Add a default case in ass_shaper_shape to proactively placate static analysers that might decide the switch is not exhaustive and we therefore don't return a value. We know it is actually exhaustive as we validate the shaper selection in ass_set_shaper.
* Return bool from ass_shaper_shapeOleg Oshmyan2020-10-223-6/+6
|
* Make harfbuzz a hard dependency; closes #199rcombs2020-10-225-59/+3
|
* ass_shaper_find_runs: don't decrement pointer beyond array startOleg Oshmyan2020-10-191-3/+5
| | | | That triggers undefined behavior.
* shape_harfbuzz: don't attempt to shape drawingsOleg Oshmyan2020-10-191-0/+5
|
* shaper: ensure drawings are in separate shape runs from textOleg Oshmyan2020-10-191-6/+5
| | | | | | | Previously, drawings would get shape_run_id = 0 from calloc. Most of the time, this separated them from text shape runs, but drawings immediately following the very first shape run would get appended to it. Make sure this cannot happen.
* shaper: don't mingle run ID and bidi embedding levelOleg Oshmyan2020-10-191-9/+6
| | | | | | | | | | | | | | | | | | | A libass-chosen shaping run boundary can coincide with a bidi embedding level boundary such that the differences in shaper_run_id and emblevel cancel out. For example: English עבריתEnglish again (with parentheses) (with no space after the Hebrew) has ass_shaper_find_runs split runs after the Hebrew, adding 1 to shape_run_id, while the RTL embed also ends in the same place, removing 1 from emblevel. As a result, two shape runs that should be separate merge together. In this example, this leads to HarfBuzz thinking that "English again (with parentheses)" is still right-to-left, so it flips the parenthesis glyphs. To avoid this, don't attempt to add these numbers together. Just require explicitly that both numbers stay constant, rather than their sum.
* shaper: use FRIBIDI_LEVEL_IS_RTL macroOleg Oshmyan2020-10-191-1/+1
|
* shaper: honor/reuse starts_new_runOleg Oshmyan2020-10-191-27/+1
| | | | | | | | | This removes duplicated code (and a not-fully-correct comment). This also ensures shaping has breaks whenever the rest of the pipeline breaks runs (e. g. for bitmap combining). In particular, this adds missing breaks on karaoke changes, which the old code didn't actually honor despite the comment.
* shaper: handle U+FFFC characters that occur in textOleg Oshmyan2020-10-191-1/+1
| | | | | | | | | U+FFFC can not only come from drawings but also be actually contained in the source text. In that case, handle it like any other character. This doesn't distinguish source-text U+FFFC from drawings whose strdup failed. But the whole rest of the pipeline treats those drawings as plain U+FFFC characters, too.
* Split glyph runs earlyOleg Oshmyan2020-10-193-42/+47
| | | | | | | | | | | | | | | | | | The "bitmap runs" that are currently used only when combining bitmaps are also relevant at other stages, mainly for VSFilter compatibility. They are not currently used because this information is not available until bitmap combining (except during shaping, which has its own "shape runs" that duplicate a good chunk of the "bitmap run" logic). Move some code around to compute run boundaries as early as possible. This lays the foundation for future commits that will make use this information in more places where it can simplify code or improve VSFilter compatibility. For VSFilter compatibility, rather than break runs immediately upon line breaks, break runs after line-leading whitespace, even in the first line. These runs correspond to VSFilter's CWord instances.
* Ignore font substitution when splitting combined bitmapsOleg Oshmyan2020-10-181-2/+0
| | | | | | | | | | | Well, that was easy. font->desc.family is the raw family name from FontName/\fn, barring the leading @ for vertical fonts. So, for reference, even if the script requests two different font names and neither exists on the system and font fallback picks the same font for both, is_new_bm_run will treat them as distinct. This is indeed the desired behaviour that matches VSFilter.
* Fix Scroll effects with rectangle \clip/\iclipOleg Oshmyan2020-10-183-4/+13
|
* Disable collision detection for Banner effect eventsOleg Oshmyan2020-10-181-0/+1
| | | | This matches VSFilter.
* Fix Scroll effect coordinatesOleg Oshmyan2020-10-181-2/+3
| | | | | | | | The coordinate computed for the text's top edge was actually used for the baseline of the text's top line, causing the first line's ascender to protrude up and the whole text to be shifted up by that ascender. (Note: in this context, bbox.y_min == text_info->lines[0].asc.)
* Don't special-case Scroll effect with bigger coordinate = 0Oleg Oshmyan2020-10-181-2/+0
| | | | VSFilter does no such thing.
* Support Banner/Scroll effects with \pos/\moveOleg Oshmyan2020-10-183-44/+43
|
* Default Banner effect to right-to-leftOleg Oshmyan2020-10-181-3/+3
| | | | That's what VSFilter does.
* Support line breaks with Banner effectOleg Oshmyan2020-10-182-12/+6
| | | | | | | | | Make Banner default to \q2, but allow explicit line breaks and \q overrides. Justify the lines according to \a etc., and wrap lines as usual if \q is overridden, but make sure to keep the left/right edge of the whole event flush with the edge of the screen at the event's start time as required by Banner. This is what VSFilter does.
* ass_render_event: simplify clip conversion to screen coordinatesOleg Oshmyan2020-10-181-53/+15
| | | | | | | | The "depends on alignment" block is useless: if use_margins, then the coordinates will be overridden, but if not, then all of the various x/y2scr... calls delegate to x/y2scr_pos... Rewrite several lines using FFMIN/FFMAX to keep them short.
* Prevent int overflow where unsigned wraparound is desiredOleg Oshmyan2020-10-182-5/+5
| | | | | | | | On exotic (or future) platforms, types such as size_t and uint32_t may be promoted to int, which allows multiplication, addition and left-shift operations on these types to overflow (and produce undefined behavior). To avoid this, make sure that the affected arithmetic operators convert any promoted operands to unsigned int by the usual arithmetic conversions.
* mult_alpha: round the productOleg Oshmyan2020-10-181-1/+1
| | | | | | For what it's worth, VSFilter does this too, and our mult_alpha now gives the same results as the corresponding code in VSFilter for all possible inputs.
* Fix mult_alpha of large argumentOleg Oshmyan2020-10-181-2/+3
| | | | | | | | | | | | This function is passed alpha values from \fade, which are restricted to nonnegative values but have no upper limit. Given a large value, the subtraction and the multiply-divide could wrap around or even overflow (in case of integer promotion to signed int). Overflow is undesirable due to undefined behavior, and wraparound is also undesirable due to VSFilter compatibility. Rewrite the expression as a simpler equivalent that does not need to deal with negative numbers and works correctly regardless of integer promotion.
* ass_lazy_track_init: avoid integer overflow in multiply-divideOleg Oshmyan2020-10-181-2/+2
| | | | | | | | | | | | 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.
* parse_tag: handle timestamps w/o overflow & like VSFilterOleg Oshmyan2020-10-181-32/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | We generally support 64-bit timestamps. However, for better VSFilter compatibility and to avoid overflow, when handling \t, \move and \fad(e), parse timestamps with 32 bits like VSFilter does and perform wraparound 32-bit subtraction. To match VSFilter results when the parsed arguments are large but the video/event durations are short, clip the current frame time and event duration to 32 bits during this. Note: we generally handle large event and video timestamps differently from VSFilter (which uses 32 bits throughout) regardless of this commit, so in a sense, this commit actually breaks our saner rendering of long- duration events while it remains VSFilter-incompatible. (It does not break large event/video timestamps per se as long as each individual event's duration fits in 31 bits.) The gain is VSFilter-compatible rendering when all video/event timestamps fit in 31 bits but override tags have values that don't (or whose differences don't) fit. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=542. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=602. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=624. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=2721. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3880. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11632. Closes https://github.com/libass/libass/pull/337.
* Fix integer overflow while parsing \fad(arg, large negative number)Oleg Oshmyan2020-10-181-1/+6
| | | | | | | | | | | If t3 is initially negative, it should be set to a value larger than the duration of the event. This triggers the `now < t3` branch in interpolate_alpha (if none of the earlier branches are taken). The same effect can be achieved by setting t3 to the duration itself. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=531. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3905. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11736.
* Factor out & improve UB-less double -> int32_t conversionOleg Oshmyan2020-10-181-7/+12
| | | | | | | | | The value may be bigger than INT32_MAX as long as its *integral part* isn't. Furthermore, make sure to avoid UB on odd platforms where int32_t limits aren't exactly representable in double, as this isn't too hard. Do assume that they're representable at all though. We won't necessarily match x86 values on such platforms, but we will avoid the undefined behavior.
* compare: set storage size before renderingDr.Smile2020-10-151-0/+1
| | | | | | This is a measure to facilitate testing with different script and video resolutions. The target PNG file size (unscaled) is used as video size.
* Scale everything from script resolution if storage size is unknownOleg Oshmyan2020-10-151-3/+1</