diff options
author | wm4 <wm4@nowhere> | 2014-11-04 23:32:02 +0100 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2014-11-05 01:52:19 +0100 |
commit | 7333bc6536ab271f5e61c227c6231efc356af6fc (patch) | |
tree | e26621c00602d75843d24455652f57e1fa2771f6 /video/vdpau_mixer.c | |
parent | 9548f6394380f98ffdc27a917f7e26dfd12bbfe8 (diff) | |
download | mpv-7333bc6536ab271f5e61c227c6231efc356af6fc.tar.bz2 mpv-7333bc6536ab271f5e61c227c6231efc356af6fc.tar.xz |
video: passthrough unknown AVPixelFormats
This is a rather radical change: instead of maintaining a whitelist of
FFmpeg formats we support, we automatically support all formats.
In general, a format which doesn't have an explicit IMGFMT_* name will
be converted to a known format through libswscale, or will be handled
by code which can treat pixel formats in a generic way using the pixel
format description, like vo_opengl.
AV_PIX_FMT_UYYVYY411 is a special-case. It's packed YUV with chroma
subsampling by 4 in both directions. Its component order is documented
as "Cb Y0 Y1 Cr Y2 Y3", meaning there's one UV sample for 4 Y samples.
This means each pixel uses 1.5 bytes (4 pixels have 1 UV sample, so
4 bytes + 2 bytes). FFmpeg can actually handle this format with its
generic mechanism in an extremely awkward way, but it doesn't work for
us. Blacklist it, and hope no similar formats will be added in the
future.
Currently, the AV_PIX_FMT_*s allowed are limited to a numeric value of
500. More is not allowed, and there are some fixed size arrays that need
to contain any possible format (look for IMGFMT_END dependencies).
We could have this simpler by replacing IMGFMT_* with AV_PIX_FMT_*
through the whole codebase. But for now, this is better, because we
can compensate for formats missing in Libav or older FFmpeg versions,
like AV_PIX_FMT_RGB0 and others.
Diffstat (limited to 'video/vdpau_mixer.c')
0 files changed, 0 insertions, 0 deletions