2010-01-30 16:57:40 +00:00
|
|
|
/*
|
|
|
|
* This file is part of MPlayer.
|
|
|
|
*
|
|
|
|
* MPlayer is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
* the Free Software Foundation; either version 2 of the License, or
|
|
|
|
* (at your option) any later version.
|
|
|
|
*
|
|
|
|
* MPlayer is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License along
|
|
|
|
* with MPlayer; if not, write to the Free Software Foundation, Inc.,
|
|
|
|
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
|
|
|
|
*/
|
|
|
|
|
2008-02-22 09:09:46 +00:00
|
|
|
#ifndef MPLAYER_IMG_FORMAT_H
|
|
|
|
#define MPLAYER_IMG_FORMAT_H
|
2002-04-13 19:14:34 +00:00
|
|
|
|
video: decouple internal pixel formats from FourCCs
mplayer's video chain traditionally used FourCCs for pixel formats. For
example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the
string 'YV12' interpreted as unsigned int. Additionally, it used to
encode information into the numeric values of some formats. The RGB
formats had their bit depth and endian encoded into the least
significant byte. Extended planar formats (420P10 etc.) had chroma
shift, endian, and component bit depth encoded. (This has been removed
in recent commits.)
Replace the FourCC mess with a simple enum. Remove all the redundant
formats like YV12/I420/IYUV. Replace some image format names by
something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P.
Add img_fourcc.h, which contains the old IDs for code that actually uses
FourCCs. Change the way demuxers, that output raw video, identify the
video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to
request the rawvideo decoder, and sh_video->imgfmt specifies the pixel
format. Like the previous hack, this is supposed to avoid the need for
a complete codecs.cfg entry per format, or other lookup tables. (Note
that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT
raw video, but this is still considered better than adding a raw video
decoder - even if trivial, it would be full of annoying lookup tables.)
The TV code has not been tested.
Some corrective changes regarding endian and other image format flags
creep in.
2012-12-23 19:03:30 +00:00
|
|
|
#include <inttypes.h>
|
2012-07-31 21:37:56 +00:00
|
|
|
#include <sys/types.h>
|
2013-08-06 20:41:30 +00:00
|
|
|
#include "mpvcore/bstr.h"
|
2009-10-19 09:50:51 +00:00
|
|
|
|
video: decouple internal pixel formats from FourCCs
mplayer's video chain traditionally used FourCCs for pixel formats. For
example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the
string 'YV12' interpreted as unsigned int. Additionally, it used to
encode information into the numeric values of some formats. The RGB
formats had their bit depth and endian encoded into the least
significant byte. Extended planar formats (420P10 etc.) had chroma
shift, endian, and component bit depth encoded. (This has been removed
in recent commits.)
Replace the FourCC mess with a simple enum. Remove all the redundant
formats like YV12/I420/IYUV. Replace some image format names by
something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P.
Add img_fourcc.h, which contains the old IDs for code that actually uses
FourCCs. Change the way demuxers, that output raw video, identify the
video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to
request the rawvideo decoder, and sh_video->imgfmt specifies the pixel
format. Like the previous hack, this is supposed to avoid the need for
a complete codecs.cfg entry per format, or other lookup tables. (Note
that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT
raw video, but this is still considered better than adding a raw video
decoder - even if trivial, it would be full of annoying lookup tables.)
The TV code has not been tested.
Some corrective changes regarding endian and other image format flags
creep in.
2012-12-23 19:03:30 +00:00
|
|
|
#if BYTE_ORDER == BIG_ENDIAN
|
|
|
|
#define MP_SELECT_LE_BE(LE, BE) BE
|
|
|
|
#else
|
|
|
|
#define MP_SELECT_LE_BE(LE, BE) LE
|
|
|
|
#endif
|
|
|
|
|
2012-12-31 00:58:25 +00:00
|
|
|
#define MP_MAX_PLANES 4
|
|
|
|
|
video: decouple internal pixel formats from FourCCs
mplayer's video chain traditionally used FourCCs for pixel formats. For
example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the
string 'YV12' interpreted as unsigned int. Additionally, it used to
encode information into the numeric values of some formats. The RGB
formats had their bit depth and endian encoded into the least
significant byte. Extended planar formats (420P10 etc.) had chroma
shift, endian, and component bit depth encoded. (This has been removed
in recent commits.)
Replace the FourCC mess with a simple enum. Remove all the redundant
formats like YV12/I420/IYUV. Replace some image format names by
something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P.
Add img_fourcc.h, which contains the old IDs for code that actually uses
FourCCs. Change the way demuxers, that output raw video, identify the
video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to
request the rawvideo decoder, and sh_video->imgfmt specifies the pixel
format. Like the previous hack, this is supposed to avoid the need for
a complete codecs.cfg entry per format, or other lookup tables. (Note
that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT
raw video, but this is still considered better than adding a raw video
decoder - even if trivial, it would be full of annoying lookup tables.)
The TV code has not been tested.
Some corrective changes regarding endian and other image format flags
creep in.
2012-12-23 19:03:30 +00:00
|
|
|
// All pixels start in byte boundaries
|
|
|
|
#define MP_IMGFLAG_BYTE_ALIGNED 0x1
|
2012-12-31 00:58:25 +00:00
|
|
|
// set if (possibly) alpha is included (might be not definitive for packed RGB)
|
|
|
|
#define MP_IMGFLAG_ALPHA 0x80
|
2012-12-26 22:12:30 +00:00
|
|
|
// Uses one component per plane (set even if it's just one plane)
|
2012-12-31 00:58:25 +00:00
|
|
|
#define MP_IMGFLAG_PLANAR 0x100
|
|
|
|
// set if it's YUV colorspace
|
|
|
|
#define MP_IMGFLAG_YUV 0x200
|
2012-12-24 00:10:57 +00:00
|
|
|
// set if it's RGB colorspace
|
|
|
|
#define MP_IMGFLAG_RGB 0x400
|
2013-05-01 14:16:03 +00:00
|
|
|
// set if it's XYZ colorspace
|
|
|
|
#define MP_IMGFLAG_XYZ 0x800
|
video: decouple internal pixel formats from FourCCs
mplayer's video chain traditionally used FourCCs for pixel formats. For
example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the
string 'YV12' interpreted as unsigned int. Additionally, it used to
encode information into the numeric values of some formats. The RGB
formats had their bit depth and endian encoded into the least
significant byte. Extended planar formats (420P10 etc.) had chroma
shift, endian, and component bit depth encoded. (This has been removed
in recent commits.)
Replace the FourCC mess with a simple enum. Remove all the redundant
formats like YV12/I420/IYUV. Replace some image format names by
something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P.
Add img_fourcc.h, which contains the old IDs for code that actually uses
FourCCs. Change the way demuxers, that output raw video, identify the
video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to
request the rawvideo decoder, and sh_video->imgfmt specifies the pixel
format. Like the previous hack, this is supposed to avoid the need for
a complete codecs.cfg entry per format, or other lookup tables. (Note
that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT
raw video, but this is still considered better than adding a raw video
decoder - even if trivial, it would be full of annoying lookup tables.)
The TV code has not been tested.
Some corrective changes regarding endian and other image format flags
creep in.
2012-12-23 19:03:30 +00:00
|
|
|
// set if the format is in a standard YUV format:
|
2012-12-31 00:58:25 +00:00
|
|
|
// - planar and yuv colorspace
|
|
|
|
// - chroma shift 0-2
|
|
|
|
// - 1-4 planes (1: gray, 2: gray/alpha, 3: yuv, 4: yuv/alpha)
|
2012-12-24 00:10:57 +00:00
|
|
|
// - 8-16 bit per pixel/plane, all planes have same depth,
|
|
|
|
// each plane has exactly one component
|
2012-12-31 00:58:25 +00:00
|
|
|
#define MP_IMGFLAG_YUV_P 0x1000
|
video: decouple internal pixel formats from FourCCs
mplayer's video chain traditionally used FourCCs for pixel formats. For
example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the
string 'YV12' interpreted as unsigned int. Additionally, it used to
encode information into the numeric values of some formats. The RGB
formats had their bit depth and endian encoded into the least
significant byte. Extended planar formats (420P10 etc.) had chroma
shift, endian, and component bit depth encoded. (This has been removed
in recent commits.)
Replace the FourCC mess with a simple enum. Remove all the redundant
formats like YV12/I420/IYUV. Replace some image format names by
something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P.
Add img_fourcc.h, which contains the old IDs for code that actually uses
FourCCs. Change the way demuxers, that output raw video, identify the
video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to
request the rawvideo decoder, and sh_video->imgfmt specifies the pixel
format. Like the previous hack, this is supposed to avoid the need for
a complete codecs.cfg entry per format, or other lookup tables. (Note
that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT
raw video, but this is still considered better than adding a raw video
decoder - even if trivial, it would be full of annoying lookup tables.)
The TV code has not been tested.
Some corrective changes regarding endian and other image format flags
creep in.
2012-12-23 19:03:30 +00:00
|
|
|
// set if in little endian, or endian independent
|
|
|
|
#define MP_IMGFLAG_LE 0x2000
|
|
|
|
// set if in big endian, or endian independent
|
|
|
|
#define MP_IMGFLAG_BE 0x4000
|
|
|
|
// set if in native (host) endian, or endian independent
|
|
|
|
#define MP_IMGFLAG_NE MP_SELECT_LE_BE(MP_IMGFLAG_LE, MP_IMGFLAG_BE)
|
2012-12-31 00:58:25 +00:00
|
|
|
|
2013-07-18 11:49:28 +00:00
|
|
|
// Exactly one of these bits is set in mp_imgfmt_desc.flags
|
|
|
|
#define MP_IMGFLAG_COLOR_CLASS_MASK \
|
|
|
|
(MP_IMGFLAG_YUV | MP_IMGFLAG_RGB | MP_IMGFLAG_XYZ)
|
2012-12-31 00:58:25 +00:00
|
|
|
|
|
|
|
struct mp_imgfmt_desc {
|
|
|
|
int id; // IMGFMT_*
|
|
|
|
int avformat; // AV_PIX_FMT_* (or AV_PIX_FMT_NONE)
|
|
|
|
const char *name; // e.g. "420p16"
|
|
|
|
int flags; // MP_IMGFLAG_* bitfield
|
video: decouple internal pixel formats from FourCCs
mplayer's video chain traditionally used FourCCs for pixel formats. For
example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the
string 'YV12' interpreted as unsigned int. Additionally, it used to
encode information into the numeric values of some formats. The RGB
formats had their bit depth and endian encoded into the least
significant byte. Extended planar formats (420P10 etc.) had chroma
shift, endian, and component bit depth encoded. (This has been removed
in recent commits.)
Replace the FourCC mess with a simple enum. Remove all the redundant
formats like YV12/I420/IYUV. Replace some image format names by
something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P.
Add img_fourcc.h, which contains the old IDs for code that actually uses
FourCCs. Change the way demuxers, that output raw video, identify the
video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to
request the rawvideo decoder, and sh_video->imgfmt specifies the pixel
format. Like the previous hack, this is supposed to avoid the need for
a complete codecs.cfg entry per format, or other lookup tables. (Note
that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT
raw video, but this is still considered better than adding a raw video
decoder - even if trivial, it would be full of annoying lookup tables.)
The TV code has not been tested.
Some corrective changes regarding endian and other image format flags
creep in.
2012-12-23 19:03:30 +00:00
|
|
|
int8_t num_planes;
|
|
|
|
int8_t chroma_xs, chroma_ys; // chroma shift (i.e. log2 of chroma pixel size)
|
2012-12-25 21:29:49 +00:00
|
|
|
int8_t align_x, align_y; // pixel size to get byte alignment and to get
|
|
|
|
// to a pixel pos where luma & chroma aligns
|
video: decouple internal pixel formats from FourCCs
mplayer's video chain traditionally used FourCCs for pixel formats. For
example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the
string 'YV12' interpreted as unsigned int. Additionally, it used to
encode information into the numeric values of some formats. The RGB
formats had their bit depth and endian encoded into the least
significant byte. Extended planar formats (420P10 etc.) had chroma
shift, endian, and component bit depth encoded. (This has been removed
in recent commits.)
Replace the FourCC mess with a simple enum. Remove all the redundant
formats like YV12/I420/IYUV. Replace some image format names by
something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P.
Add img_fourcc.h, which contains the old IDs for code that actually uses
FourCCs. Change the way demuxers, that output raw video, identify the
video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to
request the rawvideo decoder, and sh_video->imgfmt specifies the pixel
format. Like the previous hack, this is supposed to avoid the need for
a complete codecs.cfg entry per format, or other lookup tables. (Note
that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT
raw video, but this is still considered better than adding a raw video
decoder - even if trivial, it would be full of annoying lookup tables.)
The TV code has not been tested.
Some corrective changes regarding endian and other image format flags
creep in.
2012-12-23 19:03:30 +00:00
|
|
|
int8_t bytes[MP_MAX_PLANES]; // bytes per pixel (MP_IMGFLAG_BYTE_ALIGNED)
|
|
|
|
int8_t bpp[MP_MAX_PLANES]; // bits per pixel
|
|
|
|
int8_t plane_bits; // number of bits in use for plane 0
|
2012-12-31 00:58:25 +00:00
|
|
|
// chroma shifts per plane (provided for convenience with planar formats)
|
video: decouple internal pixel formats from FourCCs
mplayer's video chain traditionally used FourCCs for pixel formats. For
example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the
string 'YV12' interpreted as unsigned int. Additionally, it used to
encode information into the numeric values of some formats. The RGB
formats had their bit depth and endian encoded into the least
significant byte. Extended planar formats (420P10 etc.) had chroma
shift, endian, and component bit depth encoded. (This has been removed
in recent commits.)
Replace the FourCC mess with a simple enum. Remove all the redundant
formats like YV12/I420/IYUV. Replace some image format names by
something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P.
Add img_fourcc.h, which contains the old IDs for code that actually uses
FourCCs. Change the way demuxers, that output raw video, identify the
video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to
request the rawvideo decoder, and sh_video->imgfmt specifies the pixel
format. Like the previous hack, this is supposed to avoid the need for
a complete codecs.cfg entry per format, or other lookup tables. (Note
that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT
raw video, but this is still considered better than adding a raw video
decoder - even if trivial, it would be full of annoying lookup tables.)
The TV code has not been tested.
Some corrective changes regarding endian and other image format flags
creep in.
2012-12-23 19:03:30 +00:00
|
|
|
int8_t xs[MP_MAX_PLANES];
|
|
|
|
int8_t ys[MP_MAX_PLANES];
|
2012-12-31 00:58:25 +00:00
|
|
|
};
|
|
|
|
|
2013-11-05 20:59:26 +00:00
|
|
|
struct mp_imgfmt_desc mp_imgfmt_get_desc(int imgfmt);
|
2012-12-31 00:58:25 +00:00
|
|
|
|
video: decouple internal pixel formats from FourCCs
mplayer's video chain traditionally used FourCCs for pixel formats. For
example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the
string 'YV12' interpreted as unsigned int. Additionally, it used to
encode information into the numeric values of some formats. The RGB
formats had their bit depth and endian encoded into the least
significant byte. Extended planar formats (420P10 etc.) had chroma
shift, endian, and component bit depth encoded. (This has been removed
in recent commits.)
Replace the FourCC mess with a simple enum. Remove all the redundant
formats like YV12/I420/IYUV. Replace some image format names by
something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P.
Add img_fourcc.h, which contains the old IDs for code that actually uses
FourCCs. Change the way demuxers, that output raw video, identify the
video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to
request the rawvideo decoder, and sh_video->imgfmt specifies the pixel
format. Like the previous hack, this is supposed to avoid the need for
a complete codecs.cfg entry per format, or other lookup tables. (Note
that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT
raw video, but this is still considered better than adding a raw video
decoder - even if trivial, it would be full of annoying lookup tables.)
The TV code has not been tested.
Some corrective changes regarding endian and other image format flags
creep in.
2012-12-23 19:03:30 +00:00
|
|
|
enum mp_imgfmt {
|
|
|
|
IMGFMT_NONE = 0,
|
|
|
|
|
|
|
|
// Offset to make confusing with ffmpeg formats harder
|
|
|
|
IMGFMT_START = 1000,
|
|
|
|
|
|
|
|
// Planar YUV formats
|
|
|
|
IMGFMT_444P, // 1x1
|
|
|
|
IMGFMT_422P, // 2x1
|
|
|
|
IMGFMT_440P, // 1x2
|
|
|
|
IMGFMT_420P, // 2x2
|
|
|
|
IMGFMT_411P, // 4x1
|
|
|
|
IMGFMT_410P, // 4x4
|
|
|
|
|
|
|
|
// YUV formats with 2 bytes per plane-pixel. Formats with 9-15 bits pad the
|
|
|
|
// most significant bits with 0 (use shifts to expand them to 16 bits).
|
|
|
|
|
|
|
|
IMGFMT_444P16_LE,
|
|
|
|
IMGFMT_444P16_BE,
|
|
|
|
IMGFMT_444P14_LE,
|
|
|
|
IMGFMT_444P14_BE,
|
|
|
|
IMGFMT_444P12_LE,
|
|
|
|
IMGFMT_444P12_BE,
|
|
|
|
IMGFMT_444P10_LE,
|
|
|
|
IMGFMT_444P10_BE,
|
|
|
|
IMGFMT_444P9_LE,
|
|
|
|
IMGFMT_444P9_BE,
|
|
|
|
|
|
|
|
IMGFMT_422P16_LE,
|
|
|
|
IMGFMT_422P16_BE,
|
|
|
|
IMGFMT_422P14_LE,
|
|
|
|
IMGFMT_422P14_BE,
|
|
|
|
IMGFMT_422P12_LE,
|
|
|
|
IMGFMT_422P12_BE,
|
|
|
|
IMGFMT_422P10_LE,
|
|
|
|
IMGFMT_422P10_BE,
|
|
|
|
IMGFMT_422P9_LE,
|
|
|
|
IMGFMT_422P9_BE,
|
|
|
|
|
|
|
|
IMGFMT_420P16_LE,
|
|
|
|
IMGFMT_420P16_BE,
|
|
|
|
IMGFMT_420P14_LE,
|
|
|
|
IMGFMT_420P14_BE,
|
|
|
|
IMGFMT_420P12_LE,
|
|
|
|
IMGFMT_420P12_BE,
|
|
|
|
IMGFMT_420P10_LE,
|
|
|
|
IMGFMT_420P10_BE,
|
|
|
|
IMGFMT_420P9_LE,
|
|
|
|
IMGFMT_420P9_BE,
|
|
|
|
|
|
|
|
// Planar YUV with alpha (4th plane)
|
2012-12-26 23:58:45 +00:00
|
|
|
IMGFMT_444AP,
|
|
|
|
IMGFMT_422AP,
|
video: decouple internal pixel formats from FourCCs
mplayer's video chain traditionally used FourCCs for pixel formats. For
example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the
string 'YV12' interpreted as unsigned int. Additionally, it used to
encode information into the numeric values of some formats. The RGB
formats had their bit depth and endian encoded into the least
significant byte. Extended planar formats (420P10 etc.) had chroma
shift, endian, and component bit depth encoded. (This has been removed
in recent commits.)
Replace the FourCC mess with a simple enum. Remove all the redundant
formats like YV12/I420/IYUV. Replace some image format names by
something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P.
Add img_fourcc.h, which contains the old IDs for code that actually uses
FourCCs. Change the way demuxers, that output raw video, identify the
video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to
request the rawvideo decoder, and sh_video->imgfmt specifies the pixel
format. Like the previous hack, this is supposed to avoid the need for
a complete codecs.cfg entry per format, or other lookup tables. (Note
that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT
raw video, but this is still considered better than adding a raw video
decoder - even if trivial, it would be full of annoying lookup tables.)
The TV code has not been tested.
Some corrective changes regarding endian and other image format flags
creep in.
2012-12-23 19:03:30 +00:00
|
|
|
IMGFMT_420AP,
|
|
|
|
|
2012-12-26 23:58:45 +00:00
|
|
|
IMGFMT_444AP16_LE,
|
|
|
|
IMGFMT_444AP16_BE,
|
|
|
|
IMGFMT_444AP10_LE,
|
|
|
|
IMGFMT_444AP10_BE,
|
|
|
|
IMGFMT_444AP9_LE,
|
|
|
|
IMGFMT_444AP9_BE,
|
|
|
|
|
|
|
|
IMGFMT_422AP16_LE,
|
|
|
|
IMGFMT_422AP16_BE,
|
|
|
|
IMGFMT_422AP10_LE,
|
|
|
|
IMGFMT_422AP10_BE,
|
|
|
|
IMGFMT_422AP9_LE,
|
|
|
|
IMGFMT_422AP9_BE,
|
|
|
|
|
|
|
|
IMGFMT_420AP16_LE,
|
|
|
|
IMGFMT_420AP16_BE,
|
|
|
|
IMGFMT_420AP10_LE,
|
|
|
|
IMGFMT_420AP10_BE,
|
|
|
|
IMGFMT_420AP9_LE,
|
|
|
|
IMGFMT_420AP9_BE,
|
|
|
|
|
video: decouple internal pixel formats from FourCCs
mplayer's video chain traditionally used FourCCs for pixel formats. For
example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the
string 'YV12' interpreted as unsigned int. Additionally, it used to
encode information into the numeric values of some formats. The RGB
formats had their bit depth and endian encoded into the least
significant byte. Extended planar formats (420P10 etc.) had chroma
shift, endian, and component bit depth encoded. (This has been removed
in recent commits.)
Replace the FourCC mess with a simple enum. Remove all the redundant
formats like YV12/I420/IYUV. Replace some image format names by
something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P.
Add img_fourcc.h, which contains the old IDs for code that actually uses
FourCCs. Change the way demuxers, that output raw video, identify the
video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to
request the rawvideo decoder, and sh_video->imgfmt specifies the pixel
format. Like the previous hack, this is supposed to avoid the need for
a complete codecs.cfg entry per format, or other lookup tables. (Note
that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT
raw video, but this is still considered better than adding a raw video
decoder - even if trivial, it would be full of annoying lookup tables.)
The TV code has not been tested.
Some corrective changes regarding endian and other image format flags
creep in.
2012-12-23 19:03:30 +00:00
|
|
|
// Gray
|
|
|
|
IMGFMT_Y8,
|
|
|
|
IMGFMT_Y16_LE,
|
|
|
|
IMGFMT_Y16_BE,
|
|
|
|
|
2012-12-26 23:58:45 +00:00
|
|
|
// Gray with alpha (packed)
|
|
|
|
IMGFMT_YA8,
|
|
|
|
|
video: decouple internal pixel formats from FourCCs
mplayer's video chain traditionally used FourCCs for pixel formats. For
example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the
string 'YV12' interpreted as unsigned int. Additionally, it used to
encode information into the numeric values of some formats. The RGB
formats had their bit depth and endian encoded into the least
significant byte. Extended planar formats (420P10 etc.) had chroma
shift, endian, and component bit depth encoded. (This has been removed
in recent commits.)
Replace the FourCC mess with a simple enum. Remove all the redundant
formats like YV12/I420/IYUV. Replace some image format names by
something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P.
Add img_fourcc.h, which contains the old IDs for code that actually uses
FourCCs. Change the way demuxers, that output raw video, identify the
video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to
request the rawvideo decoder, and sh_video->imgfmt specifies the pixel
format. Like the previous hack, this is supposed to avoid the need for
a complete codecs.cfg entry per format, or other lookup tables. (Note
that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT
raw video, but this is still considered better than adding a raw video
decoder - even if trivial, it would be full of annoying lookup tables.)
The TV code has not been tested.
Some corrective changes regarding endian and other image format flags
creep in.
2012-12-23 19:03:30 +00:00
|
|
|
// Packed YUV formats (components are byte-accessed)
|
|
|
|
IMGFMT_YUYV, // Y0 U Y1 V
|
|
|
|
IMGFMT_UYVY, // U Y0 V Y1
|
|
|
|
|
|
|
|
// Y plane + packed plane for chroma
|
|
|
|
IMGFMT_NV12,
|
|
|
|
IMGFMT_NV21,
|
|
|
|
|
|
|
|
// RGB/BGR Formats
|
|
|
|
|
|
|
|
// Byte accessed (low address to high address)
|
|
|
|
IMGFMT_ARGB,
|
|
|
|
IMGFMT_BGRA,
|
|
|
|
IMGFMT_ABGR,
|
|
|
|
IMGFMT_RGBA,
|
2013-07-18 11:49:33 +00:00
|
|
|
IMGFMT_BGR24, // 3 bytes per pixel
|
video: decouple internal pixel formats from FourCCs
mplayer's video chain traditionally used FourCCs for pixel formats. For
example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the
string 'YV12' interpreted as unsigned int. Additionally, it used to
encode information into the numeric values of some formats. The RGB
formats had their bit depth and endian encoded into the least
significant byte. Extended planar formats (420P10 etc.) had chroma
shift, endian, and component bit depth encoded. (This has been removed
in recent commits.)
Replace the FourCC mess with a simple enum. Remove all the redundant
formats like YV12/I420/IYUV. Replace some image format names by
something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P.
Add img_fourcc.h, which contains the old IDs for code that actually uses
FourCCs. Change the way demuxers, that output raw video, identify the
video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to
request the rawvideo decoder, and sh_video->imgfmt specifies the pixel
format. Like the previous hack, this is supposed to avoid the need for
a complete codecs.cfg entry per format, or other lookup tables. (Note
that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT
raw video, but this is still considered better than adding a raw video
decoder - even if trivial, it would be full of annoying lookup tables.)
The TV code has not been tested.
Some corrective changes regarding endian and other image format flags
creep in.
2012-12-23 19:03:30 +00:00
|
|
|
IMGFMT_RGB24,
|
2013-07-18 11:49:33 +00:00
|
|
|
IMGFMT_RGB48_LE, // 6 bytes per pixel, uint16_t channels
|
video: decouple internal pixel formats from FourCCs
mplayer's video chain traditionally used FourCCs for pixel formats. For
example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the
string 'YV12' interpreted as unsigned int. Additionally, it used to
encode information into the numeric values of some formats. The RGB
formats had their bit depth and endian encoded into the least
significant byte. Extended planar formats (420P10 etc.) had chroma
shift, endian, and component bit depth encoded. (This has been removed
in recent commits.)
Replace the FourCC mess with a simple enum. Remove all the redundant
formats like YV12/I420/IYUV. Replace some image format names by
something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P.
Add img_fourcc.h, which contains the old IDs for code that actually uses
FourCCs. Change the way demuxers, that output raw video, identify the
video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to
request the rawvideo decoder, and sh_video->imgfmt specifies the pixel
format. Like the previous hack, this is supposed to avoid the need for
a complete codecs.cfg entry per format, or other lookup tables. (Note
that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT
raw video, but this is still considered better than adding a raw video
decoder - even if trivial, it would be full of annoying lookup tables.)
The TV code has not been tested.
Some corrective changes regarding endian and other image format flags
creep in.
2012-12-23 19:03:30 +00:00
|
|
|
IMGFMT_RGB48_BE,
|
2013-07-18 11:49:33 +00:00
|
|
|
IMGFMT_RGBA64_LE, // 8 bytes per pixel, uint16_t channels
|
2012-12-26 23:58:45 +00:00
|
|
|
IMGFMT_RGBA64_BE,
|
|
|
|
IMGFMT_BGRA64_LE,
|
|
|
|
IMGFMT_BGRA64_BE,
|
video: decouple internal pixel formats from FourCCs
mplayer's video chain traditionally used FourCCs for pixel formats. For
example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the
string 'YV12' interpreted as unsigned int. Additionally, it used to
encode information into the numeric values of some formats. The RGB
formats had their bit depth and endian encoded into the least
significant byte. Extended planar formats (420P10 etc.) had chroma
shift, endian, and component bit depth encoded. (This has been removed
in recent commits.)
Replace the FourCC mess with a simple enum. Remove all the redundant
formats like YV12/I420/IYUV. Replace some image format names by
something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P.
Add img_fourcc.h, which contains the old IDs for code that actually uses
FourCCs. Change the way demuxers, that output raw video, identify the
video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to
request the rawvideo decoder, and sh_video->imgfmt specifies the pixel
format. Like the previous hack, this is supposed to avoid the need for
a complete codecs.cfg entry per format, or other lookup tables. (Note
that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT
raw video, but this is still considered better than adding a raw video
decoder - even if trivial, it would be full of annoying lookup tables.)
The TV code has not been tested.
Some corrective changes regarding endian and other image format flags
creep in.
2012-12-23 19:03:30 +00:00
|
|
|
|
2013-11-05 20:59:26 +00:00
|
|
|
// Like e.g. IMGFMT_ARGB, but has a padding byte instead of alpha
|
|
|
|
IMGFMT_0RGB,
|
|
|
|
IMGFMT_BGR0,
|
|
|
|
IMGFMT_0BGR,
|
|
|
|
IMGFMT_RGB0,
|
|
|
|
|
|
|
|
IMGFMT_RGB0_START = IMGFMT_0RGB,
|
|
|
|
IMGFMT_RGB0_END = IMGFMT_RGB0,
|
|
|
|
|
video: decouple internal pixel formats from FourCCs
mplayer's video chain traditionally used FourCCs for pixel formats. For
example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the
string 'YV12' interpreted as unsigned int. Additionally, it used to
encode information into the numeric values of some formats. The RGB
formats had their bit depth and endian encoded into the least
significant byte. Extended planar formats (420P10 etc.) had chroma
shift, endian, and component bit depth encoded. (This has been removed
in recent commits.)
Replace the FourCC mess with a simple enum. Remove all the redundant
formats like YV12/I420/IYUV. Replace some image format names by
something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P.
Add img_fourcc.h, which contains the old IDs for code that actually uses
FourCCs. Change the way demuxers, that output raw video, identify the
video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to
request the rawvideo decoder, and sh_video->imgfmt specifies the pixel
format. Like the previous hack, this is supposed to avoid the need for
a complete codecs.cfg entry per format, or other lookup tables. (Note
that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT
raw video, but this is still considered better than adding a raw video
decoder - even if trivial, it would be full of annoying lookup tables.)
The TV code has not been tested.
Some corrective changes regarding endian and other image format flags
creep in.
2012-12-23 19:03:30 +00:00
|
|
|
// Accessed with bit-shifts (components ordered from LSB to MSB)
|
|
|
|
IMGFMT_RGB8, // r3 g3 b2
|
|
|
|
IMGFMT_BGR8,
|
|
|
|
IMGFMT_RGB4_BYTE, // r1 g2 b1 with 1 pixel per byte
|
|
|
|
IMGFMT_BGR4_BYTE,
|
|
|
|
IMGFMT_RGB4, // r1 g2 b1, bit-packed
|
|
|
|
IMGFMT_BGR4,
|
|
|
|
IMGFMT_MONO, // 1 bit per pixel, bit-packed
|
2013-02-24 15:51:29 +00:00
|
|
|
IMGFMT_MONO_W, // like IMGFMT_MONO, but inverted (white pixels)
|
video: decouple internal pixel formats from FourCCs
mplayer's video chain traditionally used FourCCs for pixel formats. For
example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the
string 'YV12' interpreted as unsigned int. Additionally, it used to
encode information into the numeric values of some formats. The RGB
formats had their bit depth and endian encoded into the least
significant byte. Extended planar formats (420P10 etc.) had chroma
shift, endian, and component bit depth encoded. (This has been removed
in recent commits.)
Replace the FourCC mess with a simple enum. Remove all the redundant
formats like YV12/I420/IYUV. Replace some image format names by
something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P.
Add img_fourcc.h, which contains the old IDs for code that actually uses
FourCCs. Change the way demuxers, that output raw video, identify the
video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to
request the rawvideo decoder, and sh_video->imgfmt specifies the pixel
format. Like the previous hack, this is supposed to avoid the need for
a complete codecs.cfg entry per format, or other lookup tables. (Note
that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT
raw video, but this is still considered better than adding a raw video
decoder - even if trivial, it would be full of annoying lookup tables.)
The TV code has not been tested.
Some corrective changes regarding endian and other image format flags
creep in.
2012-12-23 19:03:30 +00:00
|
|
|
|
|
|
|
// Accessed with bit-shifts after endian-swapping the uint16_t pixel
|
|
|
|
IMGFMT_RGB12_LE, // 4r 4g 4b 4a (LSB to MSB)
|
|
|
|
IMGFMT_RGB12_BE,
|
|
|
|
IMGFMT_RGB15_LE, // 5r 5g 5b 1a
|
|
|
|
IMGFMT_RGB15_BE,
|
|
|
|
IMGFMT_RGB16_LE, // 5r 6g 5b
|
|
|
|
IMGFMT_RGB16_BE,
|
|
|
|
IMGFMT_BGR12_LE, // 4b 4r 4g 4a
|
|
|
|
IMGFMT_BGR12_BE,
|
|
|
|
IMGFMT_BGR15_LE, // 5b 5g 5r 1a
|
|
|
|
IMGFMT_BGR15_BE,
|
|
|
|
IMGFMT_BGR16_LE, // 5b 6g 5r
|
|
|
|
IMGFMT_BGR16_BE,
|
|
|
|
|
2013-07-18 11:49:33 +00:00
|
|
|
// The first plane has 1 byte per pixel. The second plane is a palette with
|
|
|
|
// 256 entries, with each entry encoded like in IMGFMT_BGR32.
|
|
|
|
IMGFMT_PAL8,
|
video: decouple internal pixel formats from FourCCs
mplayer's video chain traditionally used FourCCs for pixel formats. For
example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the
string 'YV12' interpreted as unsigned int. Additionally, it used to
encode information into the numeric values of some formats. The RGB
formats had their bit depth and endian encoded into the least
significant byte. Extended planar formats (420P10 etc.) had chroma
shift, endian, and component bit depth encoded. (This has been removed
in recent commits.)
Replace the FourCC mess with a simple enum. Remove all the redundant
formats like YV12/I420/IYUV. Replace some image format names by
something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P.
Add img_fourcc.h, which contains the old IDs for code that actually uses
FourCCs. Change the way demuxers, that output raw video, identify the
video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to
request the rawvideo decoder, and sh_video->imgfmt specifies the pixel
format. Like the previous hack, this is supposed to avoid the need for
a complete codecs.cfg entry per format, or other lookup tables. (Note
that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT
raw video, but this is still considered better than adding a raw video
decoder - even if trivial, it would be full of annoying lookup tables.)
The TV code has not been tested.
Some corrective changes regarding endian and other image format flags
creep in.
2012-12-23 19:03:30 +00:00
|
|
|
|
|
|
|
// Planar RGB (planes are shuffled: plane 0 is G, etc.)
|
|
|
|
IMGFMT_GBRP,
|
2013-07-18 11:49:33 +00:00
|
|
|
IMGFMT_GBRP9_LE, // similar organization to IMGFMT_444P9_LE
|
2012-12-26 23:58:45 +00:00
|
|
|
IMGFMT_GBRP9_BE,
|
|
|
|
IMGFMT_GBRP10_LE,
|
|
|
|
IMGFMT_GBRP10_BE,
|
|
|
|
IMGFMT_GBRP12_LE,
|
|
|
|
IMGFMT_GBRP12_BE,
|
|
|
|
IMGFMT_GBRP14_LE,
|
|
|
|
IMGFMT_GBRP14_BE,
|
|
|
|
IMGFMT_GBRP16_LE,
|
|
|
|
IMGFMT_GBRP16_BE,
|
video: decouple internal pixel formats from FourCCs
mplayer's video chain traditionally used FourCCs for pixel formats. For
example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the
string 'YV12' interpreted as unsigned int. Additionally, it used to
encode information into the numeric values of some formats. The RGB
formats had their bit depth and endian encoded into the least
significant byte. Extended planar formats (420P10 etc.) had chroma
shift, endian, and component bit depth encoded. (This has been removed
in recent commits.)
Replace the FourCC mess with a simple enum. Remove all the redundant
formats like YV12/I420/IYUV. Replace some image format names by
something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P.
Add img_fourcc.h, which contains the old IDs for code that actually uses
FourCCs. Change the way demuxers, that output raw video, identify the
video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to
request the rawvideo decoder, and sh_video->imgfmt specifies the pixel
format. Like the previous hack, this is supposed to avoid the need for
a complete codecs.cfg entry per format, or other lookup tables. (Note
that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT
raw video, but this is still considered better than adding a raw video
decoder - even if trivial, it would be full of annoying lookup tables.)
The TV code has not been tested.
Some corrective changes regarding endian and other image format flags
creep in.
2012-12-23 19:03:30 +00:00
|
|
|
|
2013-05-01 14:16:03 +00:00
|
|
|
// XYZ colorspace, similar organization to RGB48. Even though it says "12",
|
|
|
|
// the components are stored as 16 bit, with lower 4 bits set to 0.
|
|
|
|
IMGFMT_XYZ12_LE,
|
|
|
|
IMGFMT_XYZ12_BE,
|
|
|
|
|
2013-07-18 11:49:33 +00:00
|
|
|
// Hardware accelerated formats. Plane data points to special data
|
video: decouple internal pixel formats from FourCCs
mplayer's video chain traditionally used FourCCs for pixel formats. For
example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the
string 'YV12' interpreted as unsigned int. Additionally, it used to
encode information into the numeric values of some formats. The RGB
formats had their bit depth and endian encoded into the least
significant byte. Extended planar formats (420P10 etc.) had chroma
shift, endian, and component bit depth encoded. (This has been removed
in recent commits.)
Replace the FourCC mess with a simple enum. Remove all the redundant
formats like YV12/I420/IYUV. Replace some image format names by
something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P.
Add img_fourcc.h, which contains the old IDs for code that actually uses
FourCCs. Change the way demuxers, that output raw video, identify the
video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to
request the rawvideo decoder, and sh_video->imgfmt specifies the pixel
format. Like the previous hack, this is supposed to avoid the need for
a complete codecs.cfg entry per format, or other lookup tables. (Note
that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT
raw video, but this is still considered better than adding a raw video
decoder - even if trivial, it would be full of annoying lookup tables.)
The TV code has not been tested.
Some corrective changes regarding endian and other image format flags
creep in.
2012-12-23 19:03:30 +00:00
|
|
|
// structures, instead of pixel data.
|
|
|
|
|
vdpau: split off decoder parts, use "new" libavcodec vdpau hwaccel API
Move the decoder parts from vo_vdpau.c to a new file vdpau_old.c. This
file is named so because because it's written against the "old"
libavcodec vdpau pseudo-decoder (e.g. "h264_vdpau").
Add support for the "new" libavcodec vdpau support. This was recently
added and replaces the "old" vdpau parts. (In fact, Libav is about to
deprecate and remove the "old" API without deprecation grace period,
so we have to support it now. Moreover, there will probably be no Libav
release which supports both, so the transition is even less smooth than
we could hope, and we have to support both the old and new API.)
Whether the old or new API is used is checked by a configure test: if
the new API is found, it is used, otherwise the old API is assumed.
Some details might be handled differently. Especially display preemption
is a bit problematic with the "new" libavcodec vdpau support: it wants
to keep a pointer to a specific vdpau API function (which can be driver
specific, because preemption might switch drivers). Also, surface IDs
are now directly stored in AVFrames (and mp_images), so they can't be
forced to VDP_INVALID_HANDLE on preemption. (This changes even with
older libavcodec versions, because mp_image always uses the newer
representation to make vo_vdpau.c simpler.)
Decoder initialization in the new code tries to deal with codec
profiles, while the old code always uses the highest profile per codec.
Surface allocation changes. Since the decoder won't call config() in
vo_vdpau.c on video size change anymore, we allow allocating surfaces
of arbitrary size instead of locking it to what the VO was configured.
The non-hwdec code also has slightly different allocation behavior now.
Enabling the old vdpau special decoders via e.g. --vd=lavc:h264_vdpau
doesn't work anymore (a warning suggesting the --hwdec option is
printed instead).
2013-07-27 23:49:45 +00:00
|
|
|
IMGFMT_VDPAU, // new decoder API
|
|
|
|
IMGFMT_VDPAU_MPEG1, // old API
|
video: decouple internal pixel formats from FourCCs
mplayer's video chain traditionally used FourCCs for pixel formats. For
example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the
string 'YV12' interpreted as unsigned int. Additionally, it used to
encode information into the numeric values of some formats. The RGB
formats had their bit depth and endian encoded into the least
significant byte. Extended planar formats (420P10 etc.) had chroma
shift, endian, and component bit depth encoded. (This has been removed
in recent commits.)
Replace the FourCC mess with a simple enum. Remove all the redundant
formats like YV12/I420/IYUV. Replace some image format names by
something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P.
Add img_fourcc.h, which contains the old IDs for code that actually uses
FourCCs. Change the way demuxers, that output raw video, identify the
video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to
request the rawvideo decoder, and sh_video->imgfmt specifies the pixel
format. Like the previous hack, this is supposed to avoid the need for
a complete codecs.cfg entry per format, or other lookup tables. (Note
that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT
raw video, but this is still considered better than adding a raw video
decoder - even if trivial, it would be full of annoying lookup tables.)
The TV code has not been tested.
Some corrective changes regarding endian and other image format flags
creep in.
2012-12-23 19:03:30 +00:00
|
|
|
IMGFMT_VDPAU_MPEG2,
|
|
|
|
IMGFMT_VDPAU_H264,
|
|
|
|
IMGFMT_VDPAU_WMV3,
|
|
|
|
IMGFMT_VDPAU_VC1,
|
|
|
|
IMGFMT_VDPAU_MPEG4,
|
|
|
|
|
vdpau: split off decoder parts, use "new" libavcodec vdpau hwaccel API
Move the decoder parts from vo_vdpau.c to a new file vdpau_old.c. This
file is named so because because it's written against the "old"
libavcodec vdpau pseudo-decoder (e.g. "h264_vdpau").
Add support for the "new" libavcodec vdpau support. This was recently
added and replaces the "old" vdpau parts. (In fact, Libav is about to
deprecate and remove the "old" API without deprecation grace period,
so we have to support it now. Moreover, there will probably be no Libav
release which supports both, so the transition is even less smooth than
we could hope, and we have to support both the old and new API.)
Whether the old or new API is used is checked by a configure test: if
the new API is found, it is used, otherwise the old API is assumed.
Some details might be handled differently. Especially display preemption
is a bit problematic with the "new" libavcodec vdpau support: it wants
to keep a pointer to a specific vdpau API function (which can be driver
specific, because preemption might switch drivers). Also, surface IDs
are now directly stored in AVFrames (and mp_images), so they can't be
forced to VDP_INVALID_HANDLE on preemption. (This changes even with
older libavcodec versions, because mp_image always uses the newer
representation to make vo_vdpau.c simpler.)
Decoder initialization in the new code tries to deal with codec
profiles, while the old code always uses the highest profile per codec.
Surface allocation changes. Since the decoder won't call config() in
vo_vdpau.c on video size change anymore, we allow allocating surfaces
of arbitrary size instead of locking it to what the VO was configured.
The non-hwdec code also has slightly different allocation behavior now.
Enabling the old vdpau special decoders via e.g. --vd=lavc:h264_vdpau
doesn't work anymore (a warning suggesting the --hwdec option is
printed instead).
2013-07-27 23:49:45 +00:00
|
|
|
IMGFMT_VDPAU_FIRST = IMGFMT_VDPAU,
|
video: decouple internal pixel formats from FourCCs
mplayer's video chain traditionally used FourCCs for pixel formats. For
example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the
string 'YV12' interpreted as unsigned int. Additionally, it used to
encode information into the numeric values of some formats. The RGB
formats had their bit depth and endian encoded into the least
significant byte. Extended planar formats (420P10 etc.) had chroma
shift, endian, and component bit depth encoded. (This has been removed
in recent commits.)
Replace the FourCC mess with a simple enum. Remove all the redundant
formats like YV12/I420/IYUV. Replace some image format names by
something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P.
Add img_fourcc.h, which contains the old IDs for code that actually uses
FourCCs. Change the way demuxers, that output raw video, identify the
video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to
request the rawvideo decoder, and sh_video->imgfmt specifies the pixel
format. Like the previous hack, this is supposed to avoid the need for
a complete codecs.cfg entry per format, or other lookup tables. (Note
that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT
raw video, but this is still considered better than adding a raw video
decoder - even if trivial, it would be full of annoying lookup tables.)
The TV code has not been tested.
Some corrective changes regarding endian and other image format flags
creep in.
2012-12-23 19:03:30 +00:00
|
|
|
IMGFMT_VDPAU_LAST = IMGFMT_VDPAU_MPEG4,
|
|
|
|
|
2013-08-14 13:47:18 +00:00
|
|
|
IMGFMT_VDA,
|
|
|
|
|
video: add vaapi decode and output support
This is based on the MPlayer VA API patches. To be exact it's based on
a very stripped down version of commit f1ad459a263f8537f6c from
git://gitorious.org/vaapi/mplayer.git.
This doesn't contain useless things like benchmarking hacks and the
demo code for GLX interop. Also, unlike in the original patch, decoding
and video output are split into separate source files (the separation
between decoding and display also makes pixel format hacks unnecessary).
On the other hand, some features not present in the original patch were
added, like screenshot support.
VA API is rather bad for actual video output. Dealing with older libva
versions or the completely broken vdpau backend doesn't help. OSD is
low quality and should be rather slow. In some cases, only either OSD
or subtitles can be shown at the same time (because OSD is drawn first,
OSD is prefered).
Also, libva can't decide whether it accepts straight or premultiplied
alpha for OSD sub-pictures: the vdpau backend seems to assume
premultiplied, while a native vaapi driver uses straight. So I picked
straight alpha. It doesn't matter much, because the blending code for
straight alpha I added to img_convert.c is probably buggy, and ASS
subtitles might be blended incorrectly.
Really good video output with VA API would probably use OpenGL and the
GL interop features, but at this point you might just use vo_opengl.
(Patches for making HW decoding with vo_opengl have a chance of being
accepted.)
Despite these issues, decoding seems to work ok. I still got tearing
on the Intel system I tested (Intel(R) Core(TM) i3-2350M). It was also
tested with the vdpau vaapi wrapper on a nvidia system; however this
was rather broken. (Fortunately, there is no reason to use mpv's VAAPI
support over native VDPAU.)
2013-08-09 12:01:30 +00:00
|
|
|
IMGFMT_VAAPI,
|
|
|
|
IMGFMT_VAAPI_MPEG2_IDCT,
|
|
|
|
IMGFMT_VAAPI_MPEG2_MOCO,
|
|
|
|
|
|
|
|
IMGFMT_VAAPI_FIRST = IMGFMT_VAAPI,
|
|
|
|
IMGFMT_VAAPI_LAST = IMGFMT_VAAPI_MPEG2_MOCO,
|
|
|
|
|
|
|
|
|
video: decouple internal pixel formats from FourCCs
mplayer's video chain traditionally used FourCCs for pixel formats. For
example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the
string 'YV12' interpreted as unsigned int. Additionally, it used to
encode information into the numeric values of some formats. The RGB
formats had their bit depth and endian encoded into the least
significant byte. Extended planar formats (420P10 etc.) had chroma
shift, endian, and component bit depth encoded. (This has been removed
in recent commits.)
Replace the FourCC mess with a simple enum. Remove all the redundant
formats like YV12/I420/IYUV. Replace some image format names by
something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P.
Add img_fourcc.h, which contains the old IDs for code that actually uses
FourCCs. Change the way demuxers, that output raw video, identify the
video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to
request the rawvideo decoder, and sh_video->imgfmt specifies the pixel
format. Like the previous hack, this is supposed to avoid the need for
a complete codecs.cfg entry per format, or other lookup tables. (Note
that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT
raw video, but this is still considered better than adding a raw video
decoder - even if trivial, it would be full of annoying lookup tables.)
The TV code has not been tested.
Some corrective changes regarding endian and other image format flags
creep in.
2012-12-23 19:03:30 +00:00
|
|
|
IMGFMT_END,
|
|
|
|
|
|
|
|
// Redundant format aliases for native endian access
|
|
|
|
// For all formats that have _LE/_BE, define a native-endian entry without
|
|
|
|
// the suffix.
|
|
|
|
|
|
|
|
// The IMGFMT_RGB32 and IMGFMT_BGR32 formats provide bit-shift access to
|
|
|
|
// normally byte-accessed formats:
|
|
|
|
// IMGFMT_RGB32 = r | (g << 8) | (b << 16) | (a << 24)
|
|
|
|
// IMGFMT_BGR32 = b | (g << 8) | (r << 16) | (a << 24)
|
|
|
|
IMGFMT_RGB32 = MP_SELECT_LE_BE(IMGFMT_RGBA, IMGFMT_ABGR),
|
|
|
|
IMGFMT_BGR32 = MP_SELECT_LE_BE(IMGFMT_BGRA, IMGFMT_ARGB),
|
|
|
|
|
|
|
|
IMGFMT_RGB12 = MP_SELECT_LE_BE(IMGFMT_RGB12_LE, IMGFMT_RGB12_BE),
|
|
|
|
IMGFMT_RGB15 = MP_SELECT_LE_BE(IMGFMT_RGB15_LE, IMGFMT_RGB15_BE),
|
|
|
|
IMGFMT_RGB16 = MP_SELECT_LE_BE(IMGFMT_RGB16_LE, IMGFMT_RGB16_BE),
|
|
|
|
IMGFMT_BGR12 = MP_SELECT_LE_BE(IMGFMT_BGR12_LE, IMGFMT_BGR12_BE),
|
|
|
|
IMGFMT_BGR15 = MP_SELECT_LE_BE(IMGFMT_BGR15_LE, IMGFMT_BGR15_BE),
|
|
|
|
IMGFMT_BGR16 = MP_SELECT_LE_BE(IMGFMT_BGR16_LE, IMGFMT_BGR16_BE),
|
|
|
|
IMGFMT_RGB48 = MP_SELECT_LE_BE(IMGFMT_RGB48_LE, IMGFMT_RGB48_BE),
|
2012-12-26 23:58:45 +00:00
|
|
|
IMGFMT_RGBA64 = MP_SELECT_LE_BE(IMGFMT_RGBA64_LE, IMGFMT_RGBA64_BE),
|
|
|
|
IMGFMT_BGRA64 = MP_SELECT_LE_BE(IMGFMT_BGRA64_LE, IMGFMT_BGRA64_BE),
|
video: decouple internal pixel formats from FourCCs
mplayer's video chain traditionally used FourCCs for pixel formats. For
example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the
string 'YV12' interpreted as unsigned int. Additionally, it used to
encode information into the numeric values of some formats. The RGB
formats had their bit depth and endian encoded into the least
significant byte. Extended planar formats (420P10 etc.) had chroma
shift, endian, and component bit depth encoded. (This has been removed
in recent commits.)
Replace the FourCC mess with a simple enum. Remove all the redundant
formats like YV12/I420/IYUV. Replace some image format names by
something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P.
Add img_fourcc.h, which contains the old IDs for code that actually uses
FourCCs. Change the way demuxers, that output raw video, identify the
video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to
request the rawvideo decoder, and sh_video->imgfmt specifies the pixel
format. Like the previous hack, this is supposed to avoid the need for
a complete codecs.cfg entry per format, or other lookup tables. (Note
that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT
raw video, but this is still considered better than adding a raw video
decoder - even if trivial, it would be full of annoying lookup tables.)
The TV code has not been tested.
Some corrective changes regarding endian and other image format flags
creep in.
2012-12-23 19:03:30 +00:00
|
|
|
|
|
|
|
IMGFMT_444P16 = MP_SELECT_LE_BE(IMGFMT_444P16_LE, IMGFMT_444P16_BE),
|
|
|
|
IMGFMT_444P14 = MP_SELECT_LE_BE(IMGFMT_444P14_LE, IMGFMT_444P14_BE),
|
|
|
|
IMGFMT_444P12 = MP_SELECT_LE_BE(IMGFMT_444P12_LE, IMGFMT_444P12_BE),
|
|
|
|
IMGFMT_444P10 = MP_SELECT_LE_BE(IMGFMT_444P10_LE, IMGFMT_444P10_BE),
|
|
|
|
IMGFMT_444P9 = MP_SELECT_LE_BE(IMGFMT_444P9_LE, IMGFMT_444P9_BE),
|
|
|
|
|
|
|
|
IMGFMT_422P16 = MP_SELECT_LE_BE(IMGFMT_422P16_LE, IMGFMT_422P16_BE),
|
|
|
|
IMGFMT_422P14 = MP_SELECT_LE_BE(IMGFMT_422P14_LE, IMGFMT_422P14_BE),
|
|
|
|
IMGFMT_422P12 = MP_SELECT_LE_BE(IMGFMT_422P12_LE, IMGFMT_422P12_BE),
|
|
|
|
IMGFMT_422P10 = MP_SELECT_LE_BE(IMGFMT_422P10_LE, IMGFMT_422P10_BE),
|
|
|
|
IMGFMT_422P9 = MP_SELECT_LE_BE(IMGFMT_422P9_LE, IMGFMT_422P9_BE),
|
|
|
|
|
|
|
|
IMGFMT_420P16 = MP_SELECT_LE_BE(IMGFMT_420P16_LE, IMGFMT_420P16_BE),
|
|
|
|
IMGFMT_420P14 = MP_SELECT_LE_BE(IMGFMT_420P14_LE, IMGFMT_420P14_BE),
|
|
|
|
IMGFMT_420P12 = MP_SELECT_LE_BE(IMGFMT_420P12_LE, IMGFMT_420P12_BE),
|
|
|
|
IMGFMT_420P10 = MP_SELECT_LE_BE(IMGFMT_420P10_LE, IMGFMT_420P10_BE),
|
|
|
|
IMGFMT_420P9 = MP_SELECT_LE_BE(IMGFMT_420P9_LE, IMGFMT_420P9_BE),
|
|
|
|
|
2012-12-26 23:58:45 +00:00
|
|
|
IMGFMT_444AP16 = MP_SELECT_LE_BE(IMGFMT_444AP16_LE, IMGFMT_444AP16_BE),
|
|
|
|
IMGFMT_444AP10 = MP_SELECT_LE_BE(IMGFMT_444AP10_LE, IMGFMT_444AP10_BE),
|
|
|
|
IMGFMT_444AP9 = MP_SELECT_LE_BE(IMGFMT_444AP9_LE, IMGFMT_444AP9_BE),
|
|
|
|
|
|
|
|
IMGFMT_422AP16 = MP_SELECT_LE_BE(IMGFMT_422AP16_LE, IMGFMT_422AP16_BE),
|
|
|
|
IMGFMT_422AP10 = MP_SELECT_LE_BE(IMGFMT_422AP10_LE, IMGFMT_422AP10_BE),
|
|
|
|
IMGFMT_422AP9 = MP_SELECT_LE_BE(IMGFMT_422AP9_LE, IMGFMT_422AP9_BE),
|
|
|
|
|
|
|
|
IMGFMT_420AP16 = MP_SELECT_LE_BE(IMGFMT_420AP16_LE, IMGFMT_420AP16_BE),
|
|
|
|
IMGFMT_420AP10 = MP_SELECT_LE_BE(IMGFMT_420AP10_LE, IMGFMT_420AP10_BE),
|
|
|
|
IMGFMT_420AP9 = MP_SELECT_LE_BE(IMGFMT_420AP9_LE, IMGFMT_420AP9_BE),
|
|
|
|
|
video: decouple internal pixel formats from FourCCs
mplayer's video chain traditionally used FourCCs for pixel formats. For
example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the
string 'YV12' interpreted as unsigned int. Additionally, it used to
encode information into the numeric values of some formats. The RGB
formats had their bit depth and endian encoded into the least
significant byte. Extended planar formats (420P10 etc.) had chroma
shift, endian, and component bit depth encoded. (This has been removed
in recent commits.)
Replace the FourCC mess with a simple enum. Remove all the redundant
formats like YV12/I420/IYUV. Replace some image format names by
something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P.
Add img_fourcc.h, which contains the old IDs for code that actually uses
FourCCs. Change the way demuxers, that output raw video, identify the
video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to
request the rawvideo decoder, and sh_video->imgfmt specifies the pixel
format. Like the previous hack, this is supposed to avoid the need for
a complete codecs.cfg entry per format, or other lookup tables. (Note
that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT
raw video, but this is still considered better than adding a raw video
decoder - even if trivial, it would be full of annoying lookup tables.)
The TV code has not been tested.
Some corrective changes regarding endian and other image format flags
creep in.
2012-12-23 19:03:30 +00:00
|
|
|
IMGFMT_Y16 = MP_SELECT_LE_BE(IMGFMT_Y16_LE, IMGFMT_Y16_BE),
|
2012-12-26 23:58:45 +00:00
|
|
|
|
|
|
|
IMGFMT_GBRP9 = MP_SELECT_LE_BE(IMGFMT_GBRP9_LE, IMGFMT_GBRP9_BE),
|
|
|
|
IMGFMT_GBRP10 = MP_SELECT_LE_BE(IMGFMT_GBRP10_LE, IMGFMT_GBRP10_BE),
|
|
|
|
IMGFMT_GBRP12 = MP_SELECT_LE_BE(IMGFMT_GBRP12_LE, IMGFMT_GBRP12_BE),
|
|
|
|
IMGFMT_GBRP14 = MP_SELECT_LE_BE(IMGFMT_GBRP14_LE, IMGFMT_GBRP14_BE),
|
|
|
|
IMGFMT_GBRP16 = MP_SELECT_LE_BE(IMGFMT_GBRP16_LE, IMGFMT_GBRP16_BE),
|
2013-05-01 14:16:03 +00:00
|
|
|
|
|
|
|
IMGFMT_XYZ12 = MP_SELECT_LE_BE(IMGFMT_XYZ12_LE, IMGFMT_XYZ12_BE),
|
video: decouple internal pixel formats from FourCCs
mplayer's video chain traditionally used FourCCs for pixel formats. For
example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the
string 'YV12' interpreted as unsigned int. Additionally, it used to
encode information into the numeric values of some formats. The RGB
formats had their bit depth and endian encoded into the least
significant byte. Extended planar formats (420P10 etc.) had chroma
shift, endian, and component bit depth encoded. (This has been removed
in recent commits.)
Replace the FourCC mess with a simple enum. Remove all the redundant
formats like YV12/I420/IYUV. Replace some image format names by
something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P.
Add img_fourcc.h, which contains the old IDs for code that actually uses
FourCCs. Change the way demuxers, that output raw video, identify the
video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to
request the rawvideo decoder, and sh_video->imgfmt specifies the pixel
format. Like the previous hack, this is supposed to avoid the need for
a complete codecs.cfg entry per format, or other lookup tables. (Note
that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT
raw video, but this is still considered better than adding a raw video
decoder - even if trivial, it would be full of annoying lookup tables.)
The TV code has not been tested.
Some corrective changes regarding endian and other image format flags
creep in.
2012-12-23 19:03:30 +00:00
|
|
|
};
|
2012-12-31 00:58:25 +00:00
|
|
|
|
|
|
|
static inline bool IMGFMT_IS_RGB(unsigned int fmt)
|
|
|
|
{
|
|
|
|
struct mp_imgfmt_desc desc = mp_imgfmt_get_desc(fmt);
|
2012-12-24 00:10:57 +00:00
|
|
|
return (desc.flags & MP_IMGFLAG_RGB) && desc.num_planes == 1;
|
2012-12-31 00:58:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
#define IMGFMT_RGB_DEPTH(fmt) (mp_imgfmt_get_desc(fmt).plane_bits)
|
2002-08-01 12:39:08 +00:00
|
|
|
|
video: decouple internal pixel formats from FourCCs
mplayer's video chain traditionally used FourCCs for pixel formats. For
example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the
string 'YV12' interpreted as unsigned int. Additionally, it used to
encode information into the numeric values of some formats. The RGB
formats had their bit depth and endian encoded into the least
significant byte. Extended planar formats (420P10 etc.) had chroma
shift, endian, and component bit depth encoded. (This has been removed
in recent commits.)
Replace the FourCC mess with a simple enum. Remove all the redundant
formats like YV12/I420/IYUV. Replace some image format names by
something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P.
Add img_fourcc.h, which contains the old IDs for code that actually uses
FourCCs. Change the way demuxers, that output raw video, identify the
video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to
request the rawvideo decoder, and sh_video->imgfmt specifies the pixel
format. Like the previous hack, this is supposed to avoid the need for
a complete codecs.cfg entry per format, or other lookup tables. (Note
that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT
raw video, but this is still considered better than adding a raw video
decoder - even if trivial, it would be full of annoying lookup tables.)
The TV code has not been tested.
Some corrective changes regarding endian and other image format flags
creep in.
2012-12-23 19:03:30 +00:00
|
|
|
#define IMGFMT_IS_VDPAU(fmt) \
|
|
|
|
(((fmt) >= IMGFMT_VDPAU_FIRST) && ((fmt) <= IMGFMT_VDPAU_LAST))
|
2009-02-14 08:29:45 +00:00
|
|
|
|
2013-08-14 13:47:18 +00:00
|
|
|
#define IMGFMT_IS_VDA(fmt) (((fmt) == IMGFMT_VDA))
|
|
|
|
|
video: add vaapi decode and output support
This is based on the MPlayer VA API patches. To be exact it's based on
a very stripped down version of commit f1ad459a263f8537f6c from
git://gitorious.org/vaapi/mplayer.git.
This doesn't contain useless things like benchmarking hacks and the
demo code for GLX interop. Also, unlike in the original patch, decoding
and video output are split into separate source files (the separation
between decoding and display also makes pixel format hacks unnecessary).
On the other hand, some features not present in the original patch were
added, like screenshot support.
VA API is rather bad for actual video output. Dealing with older libva
versions or the completely broken vdpau backend doesn't help. OSD is
low quality and should be rather slow. In some cases, only either OSD
or subtitles can be shown at the same time (because OSD is drawn first,
OSD is prefered).
Also, libva can't decide whether it accepts straight or premultiplied
alpha for OSD sub-pictures: the vdpau backend seems to assume
premultiplied, while a native vaapi driver uses straight. So I picked
straight alpha. It doesn't matter much, because the blending code for
straight alpha I added to img_convert.c is probably buggy, and ASS
subtitles might be blended incorrectly.
Really good video output with VA API would probably use OpenGL and the
GL interop features, but at this point you might just use vo_opengl.
(Patches for making HW decoding with vo_opengl have a chance of being
accepted.)
Despite these issues, decoding seems to work ok. I still got tearing
on the Intel system I tested (Intel(R) Core(TM) i3-2350M). It was also
tested with the vdpau vaapi wrapper on a nvidia system; however this
was rather broken. (Fortunately, there is no reason to use mpv's VAAPI
support over native VDPAU.)
2013-08-09 12:01:30 +00:00
|
|
|
#define IMGFMT_IS_VAAPI(fmt) \
|
|
|
|
(((fmt) >= IMGFMT_VAAPI_FIRST) && ((fmt) <= IMGFMT_VAAPI_LAST))
|
|
|
|
|
2013-08-14 13:47:18 +00:00
|
|
|
#define IMGFMT_IS_HWACCEL(fmt) \
|
|
|
|
(IMGFMT_IS_VDPAU(fmt) || IMGFMT_IS_VAAPI(fmt) || IMGFMT_IS_VDA(fmt))
|
2010-11-03 16:39:52 +00:00
|
|
|
|
2009-12-30 11:08:44 +00:00
|
|
|
|
2012-08-21 17:20:36 +00:00
|
|
|
struct mp_imgfmt_entry {
|
|
|
|
const char *name;
|
|
|
|
unsigned int fmt;
|
|
|
|
};
|
|
|
|
|
|
|
|
extern struct mp_imgfmt_entry mp_imgfmt_list[];
|
|
|
|
|
2012-08-28 21:58:48 +00:00
|
|
|
unsigned int mp_imgfmt_from_name(bstr name, bool allow_hwaccel);
|
2012-08-21 17:20:36 +00:00
|
|
|
const char *mp_imgfmt_to_name(unsigned int fmt);
|
|
|
|
|
video: decouple internal pixel formats from FourCCs
mplayer's video chain traditionally used FourCCs for pixel formats. For
example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the
string 'YV12' interpreted as unsigned int. Additionally, it used to
encode information into the numeric values of some formats. The RGB
formats had their bit depth and endian encoded into the least
significant byte. Extended planar formats (420P10 etc.) had chroma
shift, endian, and component bit depth encoded. (This has been removed
in recent commits.)
Replace the FourCC mess with a simple enum. Remove all the redundant
formats like YV12/I420/IYUV. Replace some image format names by
something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P.
Add img_fourcc.h, which contains the old IDs for code that actually uses
FourCCs. Change the way demuxers, that output raw video, identify the
video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to
request the rawvideo decoder, and sh_video->imgfmt specifies the pixel
format. Like the previous hack, this is supposed to avoid the need for
a complete codecs.cfg entry per format, or other lookup tables. (Note
that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT
raw video, but this is still considered better than adding a raw video
decoder - even if trivial, it would be full of annoying lookup tables.)
The TV code has not been tested.
Some corrective changes regarding endian and other image format flags
creep in.
2012-12-23 19:03:30 +00:00
|
|
|
#define vo_format_name mp_imgfmt_to_name
|
|
|
|
|
2012-12-25 13:54:42 +00:00
|
|
|
int mp_imgfmt_find_yuv_planar(int xs, int ys, int planes, int component_bits);
|
|
|
|
|
2008-02-22 09:09:46 +00:00
|
|
|
#endif /* MPLAYER_IMG_FORMAT_H */
|