From b16a6cb6c62657d3efbe69bd854287da149b59a1 Mon Sep 17 00:00:00 2001 From: wm4 Date: Thu, 20 Aug 2020 20:37:17 +0200 Subject: client API: note about libswscale corrupting memory The software rendering API makes libswscale directly write into supplied user memory. As such, weird memory corruption bugs on non-optimal buffer configurations are exposed to the user. --- libmpv/render.h | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) (limited to 'libmpv/render.h') diff --git a/libmpv/render.h b/libmpv/render.h index c9a6cec65e..ead462cbb6 100644 --- a/libmpv/render.h +++ b/libmpv/render.h @@ -390,7 +390,13 @@ typedef enum mpv_render_param_type { * target surface. It must be a multiple of the pixel size, and have space * for the surface width as specified by MPV_RENDER_PARAM_SW_SIZE. * - * It should be a multiple of 64 to facilitate fast SIMD operation. + * It should be a multiple of 64 to facilitate fast SIMD operation. Lower + * alignment might trigger slower code paths. In addition, it appears that + * if libswscale is used, stride must be at least a multiple of 16, or + * libswscale may randomly corrupt memory. The API still accepts unaligned + * values, because libswscale is not supposed to corrupt memory, and whether + * it does depends on its implementation details and bugs. If mpv is built + * with zimg (and zimg is not disabled), no problems should occur. */ MPV_RENDER_PARAM_SW_STRIDE = 19, /* @@ -407,6 +413,9 @@ typedef enum mpv_render_param_type { * will do it anyway). It is assumed that even the padding after the last * line (starting at bytepos(w, h) until (pointer + stride * h)) is * writable. + * + * It should be a aligned to 64 to facilitate fast SIMD operation. Lower + * alignment might trigger slower code paths. */ MPV_RENDER_PARAM_SW_POINTER = 20, } mpv_render_param_type; -- cgit v1.2.3