mirror of https://github.com/mpv-player/mpv
b7bf5e619f
This is yet another unfortunate side effect of the width % SLICE_W == 0 special case. While looping through these rectangles, the rc->x1 value on the final loop can be greater than the actual total width. This will cause a buffer overflow if using the mp_draw_sub_overlay API. 2 of the current VOs that use that work around it by adjusting the values returned, but the better fix is to correct what's actually given in the rectangles so you can safely use the values. As for the fix, it's simply ensuring that rc->x1 doesn't extend beyond p->w with a MPCLAMP. Previously, the code would always naively add SLICE_W (256) to rc->x0 which would easily extend past the actual width in many cases. The adjustments in vo_vaapi and vo_dmabuf_wayland are dropped and in theory vo_direct3d should work now since we can just trust the values given to us in the rectangles. How nice. |
||
---|---|---|
.. | ||
decode | ||
filter | ||
out | ||
csputils.c | ||
csputils.h | ||
cuda.c | ||
d3d.c | ||
d3d.h | ||
drmprime.c | ||
fmt-conversion.c | ||
fmt-conversion.h | ||
hwdec.c | ||
hwdec.h | ||
image_loader.c | ||
image_loader.h | ||
image_writer.c | ||
image_writer.h | ||
img_format.c | ||
img_format.h | ||
mp_image.c | ||
mp_image.h | ||
mp_image_pool.c | ||
mp_image_pool.h | ||
repack.c | ||
repack.h | ||
sws_utils.c | ||
sws_utils.h | ||
vaapi.c | ||
vaapi.h | ||
vdpau.c | ||
vdpau.h | ||
vdpau_functions.inc | ||
vdpau_mixer.c | ||
vdpau_mixer.h | ||
zimg.c | ||
zimg.h |