draw_bmp: fix overflowing coordinates in mark_rcs

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.

1 files changed, 2 insertions, 1 deletions

diff --git a/sub/draw_bmp.c b/sub/draw_bmp.c
index 2e19c6c3b8..58db162a56 100644
--- a/sub/draw_bmp.c
+++ b/sub/draw_bmp.c
@@ -968,7 +968,8 @@ static void mark_rcs(struct mp_draw_sub_cache *p, struct rc_grid *gr)
                 rc->y0 = MPMIN(rc->y0, y);
                 rc->y1 = MPMAX(rc->y1, y + 1);
                 rc->x0 = MPMIN(rc->x0, xpos + s->x0);
-                rc->x1 = MPMAX(rc->x1, xpos + s->x1);
+                // Ensure this does not extend beyond the total width
+                rc->x1 = MPCLAMP(xpos + s->x1, rc->x1, p->w);
             }
         }
     }