diff options
author | rcombs <rcombs@rcombs.me> | 2020-09-16 23:37:02 -0500 |
---|---|---|
committer | Oleg Oshmyan <chortos@inbox.lv> | 2020-09-19 17:49:41 +0300 |
commit | 9b04e56ff6e1ed82bc48ac7307e627bdbbaf082d (patch) | |
tree | 6a0ca65efd623df0dfbce30aecef185d5c60fc98 /libass/ass_fontselect.c | |
parent | 6bb17b7e7b783844e66335a7293c82c93ea757d3 (diff) | |
download | libass-9b04e56ff6e1ed82bc48ac7307e627bdbbaf082d.tar.bz2 libass-9b04e56ff6e1ed82bc48ac7307e627bdbbaf082d.tar.xz |
ass_parse: avoid UB and match vsfilter on negative-accel color animation
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.
Diffstat (limited to 'libass/ass_fontselect.c')
0 files changed, 0 insertions, 0 deletions