mirror of
https://github.com/mpv-player/mpv
synced 2025-01-04 05:52:09 +00:00
a9116ddd38
The special thing about this format is 1. mpv assigns the component ID 4 to alpha, and component IDs 2 and 3 are not present, which causes some messy details. 2. zimg always wants the alpha plane as plane 3, and plane 1 and 2 are not present, while FFmpeg/mpv put the alpha plane as plane 1. In theory, 2. could be avoided, since FFmpeg actually doesn't have a any 2 plane formats (alpha is either packed, or plane 3). But having to skip "empty" planes would break expectations. zplanes is not equivalent to the mpv plane count (actually it was always used this way), while zimg does not really have a plane count, but does, in this case, only use plane 0 and 3, while 2 and 3 are unused and unset. z_planes[] (not zplanes) is now always valid for all 4 array entries (because it uses zimg indexes), but a -1 entry means it's an unused plane. I wonder if these conventions taken by mpv/zimg are not just causing extra work. Maybe component IDs should just be indexes by the "natural" order (e.g. R-G-B-A, Y-U-V-A, Y-A), and alpha should be represented as a field that specifies the component ID for it, or just strictly assume that 2/4 component formats always use the last component for alpha. |
||
---|---|---|
.. | ||
decode | ||
filter | ||
out | ||
csputils.c | ||
csputils.h | ||
cuda.c | ||
d3d.c | ||
d3d.h | ||
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_pool.c | ||
mp_image_pool.h | ||
mp_image.c | ||
mp_image.h | ||
sws_utils.c | ||
sws_utils.h | ||
vaapi.c | ||
vaapi.h | ||
vdpau_functions.inc | ||
vdpau_mixer.c | ||
vdpau_mixer.h | ||
vdpau.c | ||
vdpau.h | ||
zimg.c | ||
zimg.h |