RepoMirrors
/
mpv
mirror of https://github.com/mpv-player/mpv
1
0
Fork 0
Code Issues Releases Wiki Activity

client API: update alignment requirements for software rendering 

Previous commit fixes it for libswscale. The libzimg path has extra code
to copy by slice, but it still may access pixel groups using normal
memory accesses (for example, reading rgba pixel data via uint32_t), so
document a minimum alignment requirement per pixel format.
This commit is contained in:
wm4 2020-09-17 15:25:49 +02:00
parent 083adf97e1
commit 76fb001c42
1 changed files with 12 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
libmpv/render.h
View File

@ -370,9 +370,11 @@ typedef enum mpv_render_param_type {
* address 0), the "0" component contains uninitialized garbage (often * address 0), the "0" component contains uninitialized garbage (often
* the value 0, but not necessarily; the bad naming is inherited from * the value 0, but not necessarily; the bad naming is inherited from
* FFmpeg) * FFmpeg)
* Pixel alignment size: 4 bytes
* "rgb24" * "rgb24"
* 3 bytes per pixel RGB. This is strongly discouraged because it is * 3 bytes per pixel RGB. This is strongly discouraged because it is
* very slow. * very slow.
* Pixel alignment size: 1 bytes
* other * other
* The API may accept other pixel formats, using mpv internal format * The API may accept other pixel formats, using mpv internal format
* names, as long as it's internally marked as RGB, has exactly 1 * names, as long as it's internally marked as RGB, has exactly 1
@ -390,13 +392,15 @@ typedef enum mpv_render_param_type {
* target surface. It must be a multiple of the pixel size, and have space * 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. * for the surface width as specified by MPV_RENDER_PARAM_SW_SIZE.
* *
* It should be a multiple of 64 to facilitate fast SIMD operation. Lower * Both stride and pointer value should be a multiple of 64 to facilitate
* alignment might trigger slower code paths. In addition, it appears that * fast SIMD operation. Lower alignment might trigger slower code paths,
* if libswscale is used, stride must be at least a multiple of 16, or * and in the worst case, will copy the entire target frame. If mpv is built
* libswscale may randomly corrupt memory. The API still accepts unaligned * with zimg (and zimg is not disabled), the performance impact might be
* values, because libswscale is not supposed to corrupt memory, and whether * less.
* it does depends on its implementation details and bugs. If mpv is built * In either cases, the pointer and stride must be aligned at least to the
* with zimg (and zimg is not disabled), no problems should occur. * pixel alignment size. Otherwise, crashes and undefined behavior is
* possible on platforms which do not support unaligned accesses (either
* through normal memory access or aligned SIMD memory access instructions).
*/ */
MPV_RENDER_PARAM_SW_STRIDE = 19, MPV_RENDER_PARAM_SW_STRIDE = 19,
/* /*
@ -414,8 +418,7 @@ typedef enum mpv_render_param_type {
* line (starting at bytepos(w, h) until (pointer + stride * h)) is * line (starting at bytepos(w, h) until (pointer + stride * h)) is
* writable. * writable.
* *
* It should be a aligned to 64 to facilitate fast SIMD operation. Lower * See MPV_RENDER_PARAM_SW_STRIDE for alignment requirements.
* alignment might trigger slower code paths.
*/ */
MPV_RENDER_PARAM_SW_POINTER = 20, MPV_RENDER_PARAM_SW_POINTER = 20,
} mpv_render_param_type; } mpv_render_param_type;