Plugins (alphablend): Fix blending and associated crashes due to buffer overruns #383
Conversation
… the given pixel count.
… to `n` to mirror similar functions.
| uint8_t *dest_row_ptr = visual_video_get_pixels (dest); | ||
|
|
||
| uint8_t alpha = progress * 255; | ||
| BlendFunc blend_func = get_blend_func (depth); |
There was a problem hiding this comment.
get_blend_func can return NULL. If we keep allowing it to, we likely need a check for NULL somewhere around here?
There was a problem hiding this comment.
The default case is unreachable and largely included to silence compiler warnings about enum values unaccounted for (e.g. VISUAL_VIDEO_DEPTH_NONE and VISUAL_DEPTH_NONE_ALL).
We don't have unreachable() in C99 or C11 so I returned a NULL instead. Would you prefer abort()?
There was a problem hiding this comment.
@kaixiong I would favor some flavor of abort or assert — something with a message —, yes, maybe using libvisual's log_and_exit? (Maybe we need one more check for that for lv_checks.h.)
| uint8_t *src2_row_ptr = visual_video_get_pixels (src2); | ||
| uint8_t *dest_row_ptr = visual_video_get_pixels (dest); | ||
|
|
||
| uint8_t alpha = progress * 255; |
There was a problem hiding this comment.
The original formula was uint8_t a = alpha * (1/255.0); with rather different results, unless I am missing something. Was the old formula just wrong and the new formula fixes it or is this change accidental?
PS: If that that part of the change could be made a separate commit, I think it could help Git history clarity.
There was a problem hiding this comment.
The existing code is wrong. Across the morph transition, alpha should move from 0 to 255 as progress is increased from 0.0 to 1.0. This increases the weight of the blended-in image as the morph progresses.
Oddly enough, 0.4.x has the correct (and equivalent) formula so I might've inverted the two ranges due to confusion.
Let me split this change out into a separate commit.
The alphablend morph uses the blending routines
visual_alpha_blend_nn()wrongly. It passes the pixel buffer size in bytes instead of pixel count for thesizeparameter. Since buffer size is always equal or greater than pixel count (bytes per pixel >= 1 and row padding >= 0), this causes buffer overruns.