summaryrefslogtreecommitdiffstats
path: root/libass
Commit message (Collapse)AuthorAgeFilesLines
* Remove arbitrary bitmap size limitRodger Combs2017-02-141-2/+2
| | | | | | | | 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
* Don't limit size of "uuencoded" font linesOleg Oshmyan2017-02-141-6/+1
|
* Fix decode_font when size % 4 != 0 or data contains illegal bytesOleg Oshmyan2017-02-141-22/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* ass_lazy_track_init: handle negative PlayResX/PlayResYOleg Oshmyan2017-02-141-6/+6
| | | | Like VSFilter, treat negative values the same as missing values.
* string2timecode: don't truncate milliseconds to intOleg Oshmyan2017-02-141-1/+1
| | | | | | | | | 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.
* Reuse numpad2align in parse_tagOleg Oshmyan2017-02-144-31/+27
|
* Fix parsing of unusual Alignment values in ASS style definitionsOleg Oshmyan2017-02-141-6/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Don't treat :;<=>? as hexadecimal digits in color headersOleg Oshmyan2017-02-141-1/+1
| | | | Oops.
* Explicitly handle FcPatternGetString(FC_POSTSCRIPT_NAME) mismatchOleg Oshmyan2017-02-111-3/+4
| | | | | | | This does not affect functionality in any way, but it hopefully makes the logic easier to follow. Resolves CID 175691.
* Reduce precision of border width in outline cache keysOleg Oshmyan2017-01-312-5/+5
| | | | | | | 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.
* Reflect border_scale in outline cache keysOleg Oshmyan2017-01-311-4/+4
| | | | | | | | | 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.
* render: remove redundant has_clipsDr.Smile2017-01-312-19/+4
| | | | | | | | | | | | | 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.
* render_api: do not discard old images on reconfigurationwm42017-01-131-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* render: clip BorderStyle=4 against screenwm42017-01-111-7/+15
| | | | | | | | 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.
* Bump ABI version and release 0.13.60.13.6Oleg Oshmyan2017-01-032-4/+4
| | | | | | 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.
* Release 0.13.50.13.5Oleg Oshmyan2016-12-292-2/+2
|
* api: make ass_set_cache_limits() work on total bitmap cache sizesDr.Smile2016-12-292-4/+16
| | | | | | Previously was possible to set only bitmap_max_size, now requested memory amount is divided between bitmap_max_size and composite_max_size.
* Fix memory leak when Language header is defined more than onceOleg Oshmyan2016-12-291-0/+1
| | | | | Discovered by OSS-Fuzz. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=229.
* parse_tag: don't consume *end == ')' when called recursivelyOleg Oshmyan2016-12-291-1/+1
| | | | | This did not cause any problems, but it's nicer to guarantee that the return value is <= end.
* Fix buffer overread in parse_tag when end points to a spaceOleg Oshmyan2016-12-291-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* directwrite: drop SAL annotationsOleg Oshmyan2016-12-281-16/+16
| | | | | | | 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.
* ass_strtod: correctly convert large negative exponentsOleg Oshmyan2016-11-211-4/+43
| | | | | | | | | | | | 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.
* ass_strtod: don't cast away constOleg Oshmyan2016-11-211-2/+3
|
* ass_strtod: handle overflowing exponentsOleg Oshmyan2016-11-211-7/+37
| | | | | | | | | | | | 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: skip leading zeros in mantissaOleg Oshmyan2016-11-211-3/+14
| | | | | | | | 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.
* ass_strtod: don't report overflow for 0.0e[huge exponent]Oleg Oshmyan2016-11-211-1/+3
|
* ass_strtod: use size_t for substring lengthsOleg Oshmyan2016-11-211-18/+19
| | | | | This fixes overflow on extremely long input strings. See libass#244.
* Add text justificationDan Oscarsson2016-11-125-3/+48
| | | | | | | | | | | | | | | | | | | | | | | 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.
* Release 0.13.40.13.4Grigori Goronzy2016-10-052-2/+2
|
* Remove unused variableGrigori Goronzy2016-10-051-3/+0
|
* Fix line wrapping mode 0/3 bugsGrigori Goronzy2016-10-051-1/+4
| | | | | | | | | | | | | | | | | | 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
* Fix blur coefficient calculation buffer overflowGrigori Goronzy2016-10-041-1/+1
| | | | | 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.
* Fix memory leaksGrigori Goronzy2016-10-041-0/+1
| | | | Found by fuzzer test case id:000051,sig:11,sync:fuzzer3,src:004221.
* shaper: fix reallocationGrigori Goronzy2016-10-041-0/+1
| | | | | | | | 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.
* Release 0.13.30.13.3Grigori Goronzy2016-09-242-2/+2
|
* bitmap: use calloc instead of malloc/memsetRodger Combs2016-09-246-30/+25
| | | | This can improve perf somewhat with large bitmaps
* cache: fix ownership tracking issues of ASS_FontDr.Smile2016-07-162-1/+2
|
* font load from dir: use MSGL_INFO instead of MSGL_WARNAvi Halachmi (:avih)2016-07-111-1/+1
| | | | | | | | 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
* render: add refcounting functionality to image listsDr.Smile2016-06-303-27/+43
|
* cache: keep referenced cache values alive after ass_cache_empty()Dr.Smile2016-06-302-86/+106
|
* render: keep track of any associated resources within ASS_ImageDr.Smile2016-06-303-115/+84
| | | | | That resources can be cached composite bitmap or raw bitmap buffer. Consequently, free lists are no longer needed.
* cache: keep ref_count of all active objects nonzeroDr.Smile2016-06-307-106/+164
|
* cache: replace size_func with parameter in ass_cache_commit()Dr.Smile2016-06-305-55/+34
|
* cache: remove ass_cache_cancel(), cache failures insteadDr.Smile2016-06-305-184/+228
|
* cache: switch to gradual cache clearingDr.Smile2016-06-308-198/+316
| | | | | | | | | | | 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.
* shaper: drop RTL base direction for RTL font encodingsGrigori Goronzy2016-06-101-8/+4
| | | | | | | | 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.
* font: fix NULL pointer dereferenceHannes Domani2016-05-231-0/+3
|
* rasterizer: drop outlines with points at too large coordinatesDr.Smile2016-04-231-1/+12
| | | | | | | Such points can overflow internal calculations and usually produced as a result of NaN to integer conversion. Should fix #210.
* directwrite: fix leaks of IDWriteFontFamily/IDWriteFontCollectionHannes Domani2016-03-271-0/+4
|
* Release 0.13.20.13.2Oleg Oshmyan2016-02-201-3/+3
|
* Document default value for ass_set_check_readorderOleg Oshmyan2016-02-201-0/+1
|
* ass: handle movement==0 in ass_step_sub()wm42016-02-041-6/+12
| | | | Finds the start of the subtitle at "now".
* font: remove unused functionwm42016-01-142-27/+0
|
* ass: add ass_set_check_readorder() API functionwm42015-12-313-3/+22
| | | | | | | | 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.)
* ass: declare mixing ass_flush_events() and ass_process_chunk() allowedwm42015-12-311-1/+2
| | | | | | This was always the intention, but the wording could be read as if this is not allowed. There was a bug that broke ass_flush_events() too, which gives all the more reason to clarify this.
* ass: reset the ReadOrder bitmap on ass_flush_events()wm42015-12-201-0/+3
| | | | | Otherwise, ass_process_chunk() will reject events that were previously removed with ass_flush_events(), which is nonsense.
* coretext: fix NULL CFStringRef dereferencewm42015-12-091-0/+2
|
* Release 0.13.10.13.1Oleg Oshmyan2015-12-011-1/+1
|
* coretext: don't fetch character set when it isn't neededOleg Oshmyan2015-12-011-3/+3
| | | | | This avoids unnecessary work and fixes a memory leak: the character set wasn't released when code == 0.
* fontselect: destroy private data of fonts that fail to be addedOleg Oshmyan2015-12-011-0/+4
|
* fontselect: fix bool return valuesOleg Oshmyan2015-12-011-6/+6
| | | | | | | Return true on success and false on failure. get_font_info was actually inconsistent, returning false both on success and on failure due to the face not being scalable.
* coretext: don't forget to release font format attributeOleg Oshmyan2015-11-071-0/+2
|
* fontselect: replace is_postscript flag with check_postscript functionOleg Oshmyan2015-11-045-86/+133
| | | | | | | | | | | | | | | | | | | | | | | DirectWrite does not provide fast access to the is_postscript flag, requiring each font to be loaded before its format can be determined. Eagerly doing this for every installed font can be quite slow, on the order of seconds. To improve performance, ask the font provider for this information only when it is actually needed, i.e. when one of the font's full names or its PostScript name matches a requested font name and we need to know whether to accept this match. The return value of check_postscript is not cached in this commit. This makes repeated calls slower than accessing is_postscript was. This should not be a problem, but if it is, the value can be cached (or precomputed) by font providers in their font private data. This commit also potentially increases the memory usage of some font providers by retaining data structures needed to implement check_postscript in their font private data. This should not be a problem either, but if it is, the value of check_postscript can be precomputed by all providers other than DirectWrite.
* directwrite: improve error handlingOleg Oshmyan2015-10-301-23/+51
| | | | | | | | | | * Check malloc and calloc return values. * Abort if a name can't be fetched, rather than supply a NULL string to fontselect causing it to crash. * Make sure to free all allocated memory. * Always check FAILED(hr) before using the value of any output argument returned by DirectWrite, because it is not clear whether they are guaranteed to have correct values in case of error.
* directwrite: slightly