2010-01-30 16:57:40 +00:00
|
|
|
/*
|
2015-04-13 07:36:54 +00:00
|
|
|
* This file is part of mpv.
|
2010-01-30 16:57:40 +00:00
|
|
|
*
|
video/fmt-conversion, img_format: change license to LGPL
The problem with fmt-conversion.h is that "lucabe", who disagreed with
LGPL, originally wrote it. But it was actually rewritten by "reimar"
later. The original switch statement was replaced with a lookup table.
No code other than the imgfmt2pixfmt() function signature survives.
Neither the format pairs (PIXFMT<->IMGFMT), nor the concept of mapping
them, can be copyrighted.
So changing the license should be fine, because reimar and all other
authors involved with the new code agreed to LGPL.
We also don't consider format pairs added later as copyrightable.
(The direct-mapping idea mentioned in the "Copyright" file seems
attractive, and I might implement in later anyway.)
Likewise, there might be some format names added to img_format.h, which
are not covered by relicensing agreements. These all affect "later"
additions, and they follow either the FFmpeg PIXFMT naming or some other
pre-existing logic, so this should be fine.
2017-06-18 13:12:11 +00:00
|
|
|
* mpv is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
* License as published by the Free Software Foundation; either
|
|
|
|
* version 2.1 of the License, or (at your option) any later version.
|
2010-01-30 16:57:40 +00:00
|
|
|
*
|
2015-04-13 07:36:54 +00:00
|
|
|
* mpv is distributed in the hope that it will be useful,
|
2010-01-30 16:57:40 +00:00
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
video/fmt-conversion, img_format: change license to LGPL
The problem with fmt-conversion.h is that "lucabe", who disagreed with
LGPL, originally wrote it. But it was actually rewritten by "reimar"
later. The original switch statement was replaced with a lookup table.
No code other than the imgfmt2pixfmt() function signature survives.
Neither the format pairs (PIXFMT<->IMGFMT), nor the concept of mapping
them, can be copyrighted.
So changing the license should be fine, because reimar and all other
authors involved with the new code agreed to LGPL.
We also don't consider format pairs added later as copyrightable.
(The direct-mapping idea mentioned in the "Copyright" file seems
attractive, and I might implement in later anyway.)
Likewise, there might be some format names added to img_format.h, which
are not covered by relicensing agreements. These all affect "later"
additions, and they follow either the FFmpeg PIXFMT naming or some other
pre-existing logic, so this should be fine.
2017-06-18 13:12:11 +00:00
|
|
|
* GNU Lesser General Public License for more details.
|
2010-01-30 16:57:40 +00:00
|
|
|
*
|
video/fmt-conversion, img_format: change license to LGPL
The problem with fmt-conversion.h is that "lucabe", who disagreed with
LGPL, originally wrote it. But it was actually rewritten by "reimar"
later. The original switch statement was replaced with a lookup table.
No code other than the imgfmt2pixfmt() function signature survives.
Neither the format pairs (PIXFMT<->IMGFMT), nor the concept of mapping
them, can be copyrighted.
So changing the license should be fine, because reimar and all other
authors involved with the new code agreed to LGPL.
We also don't consider format pairs added later as copyrightable.
(The direct-mapping idea mentioned in the "Copyright" file seems
attractive, and I might implement in later anyway.)
Likewise, there might be some format names added to img_format.h, which
are not covered by relicensing agreements. These all affect "later"
additions, and they follow either the FFmpeg PIXFMT naming or some other
pre-existing logic, so this should be fine.
2017-06-18 13:12:11 +00:00
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
|
|
|
* License along with mpv. If not, see <http://www.gnu.org/licenses/>.
|
2010-01-30 16:57:40 +00:00
|
|
|
*/
|
|
|
|
|
2012-12-31 00:58:25 +00:00
|
|
|
#include <assert.h>
|
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 <string.h>
|
2012-12-31 00:58:25 +00:00
|
|
|
|
vf_scale: replace ancient fallback image format selection
If video output and VO don't support the same format, a conversion
filter needs to be insert. Since a VO can support multiple formats, and
the filter chain also can deal with multiple formats, you basically have
to pick from a huge matrix of possible conversions.
The old MPlayer code had a quite naive algorithm: it first checked
whether any conversion from the list of preferred conversions matched,
and if not, it was falling back on checking a hardcoded list of output
formats (more or less sorted by quality). This had some unintended side-
effects, like not using obvious "replacement" formats, selecting the
wrong colorspace, selecting a bit depth that is too high or too low, and
more.
Use avcodec_find_best_pix_fmt_of_list() provided by FFmpeg instead. This
function was made for this purpose, and should select the "best" format.
Libav provides a similar function, but with a different name - there is
a function with the same name in FFmpeg, but it has different semantics
(I'm not sure if Libav or FFmpeg fucked up here).
This also removes handling of VFCAP_CSP_SUPPORTED vs.
VFCAP_CSP_SUPPORTED_BY_HW, which has no meaning anymore, except possibly
for filter chains with multiple scale filters.
Fixes #1494.
2015-01-21 17:33:47 +00:00
|
|
|
#include <libavcodec/avcodec.h>
|
video: add pixel component location metadata
I thought I'd probably want something like this, so the hardcoded stuff
in repack.c can be removed eventually. Of course this has no purpose at
all, and will not have any. (For now, this provides only metadata, and
nothing uses it, apart from the "test" that dumps it as text.)
This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite,
because the format is 100% useless). Support for some mpv-only formats
is missing, ironically.
The code goes through _lengths_ to try to make sense out of the FFmpeg
AVPixFmtDescriptor data. Which is even more amazing that the new
metadata basically mirrors pixdesc, and just adds to it. Considering
code complexity and speed issues (it takes time to crunch through all
this shit all the time), and especially the fact that pixdesc is very
_incomplete_, it would probably better to have our own table to all
formats. But then we'd not scramble every time FFmpeg adds a new format,
which would be annoying. On the other hand, by using pixdesc, we get the
excitement to see whether this code will work, or break everything in
catastrophic ways.
The data structure still sucks a lot. Maybe I'll redo it again. The text
dump is weirdly differently formatted than the C struct - because I'm
not happy with the representation. Maybe I'll redo it all over again.
In summary: this commit does nothing.
2020-05-17 22:24:31 +00:00
|
|
|
#include <libavutil/imgutils.h>
|
2012-12-31 00:58:25 +00:00
|
|
|
#include <libavutil/pixfmt.h>
|
|
|
|
#include <libavutil/pixdesc.h>
|
|
|
|
|
2015-09-10 20:13:52 +00:00
|
|
|
#include "config.h"
|
|
|
|
|
2012-11-09 00:06:43 +00:00
|
|
|
#include "video/img_format.h"
|
2012-12-31 00:58:25 +00:00
|
|
|
#include "video/mp_image.h"
|
|
|
|
#include "video/fmt-conversion.h"
|
2001-10-31 22:04:28 +00:00
|
|
|
|
2014-04-14 18:19:44 +00:00
|
|
|
struct mp_imgfmt_entry {
|
|
|
|
const char *name;
|
2020-05-20 16:25:14 +00:00
|
|
|
// Valid if flags!=0.
|
|
|
|
// This can be incomplete, and missing fields are filled in:
|
|
|
|
// - sets num_planes and bpp[], derived from comps[] (rounds to bytes)
|
|
|
|
// - sets MP_IMGFLAG_GRAY, derived from comps[]
|
|
|
|
// - sets MP_IMGFLAG_ALPHA, derived from comps[]
|
|
|
|
// - sets align_x/y if 0, derived from chroma shift
|
|
|
|
// - sets xs[]/ys[] always, derived from num_planes/chroma_shift
|
|
|
|
// - sets MP_IMGFLAG_HAS_COMPS|MP_IMGFLAG_NE if num_planes>0
|
|
|
|
// - sets MP_IMGFLAG_TYPE_UINT if no other type set
|
|
|
|
// - sets id to mp_imgfmt_list[] implied format
|
2020-04-21 20:56:45 +00:00
|
|
|
struct mp_imgfmt_desc desc;
|
2014-04-14 18:19:44 +00:00
|
|
|
};
|
|
|
|
|
2020-05-20 16:25:14 +00:00
|
|
|
#define FRINGE_GBRP(def, dname, b) \
|
img_format: add some mpv-only helper formats
Utterly useless, but the intention is to make dealing with corner case
pixel formats (forced upon us by FFmpeg, very rarely) less of a pain.
The zimg wrapper will use them. (It already supports these formats
automatically, but it will help with its internals.)
Y1 is considered RGB, even though gray formats are generally treated as
YUV for various reasons. mpv will default all YUV formats to limited
range internally, which makes no sense for a 1 bit format, so this is a
problem. I wanted to avoid that mp_image_params_guess_csp() (which
applies the default) explicitly checks for an image format, so although
a bit janky, this seems to be a good solution, especially because I
really don't give a shit about these formats, other than having to
handle them. It's notable that AV_PIX_FMT_MONOBLACK (also 1 bit gray,
just packed) already explicitly marked itself as RGB.
2020-04-23 10:47:13 +00:00
|
|
|
[def - IMGFMT_CUST_BASE] = { \
|
|
|
|
.name = dname, \
|
2020-05-20 16:25:14 +00:00
|
|
|
.desc = { .flags = MP_IMGFLAG_COLOR_RGB, \
|
|
|
|
.comps = { {2, 0, 8, (b) - 8}, {0, 0, 8, (b) - 8}, \
|
|
|
|
{1, 0, 8, (b) - 8}, }, }}
|
img_format: add some mpv-only helper formats
Utterly useless, but the intention is to make dealing with corner case
pixel formats (forced upon us by FFmpeg, very rarely) less of a pain.
The zimg wrapper will use them. (It already supports these formats
automatically, but it will help with its internals.)
Y1 is considered RGB, even though gray formats are generally treated as
YUV for various reasons. mpv will default all YUV formats to limited
range internally, which makes no sense for a 1 bit format, so this is a
problem. I wanted to avoid that mp_image_params_guess_csp() (which
applies the default) explicitly checks for an image format, so although
a bit janky, this seems to be a good solution, especially because I
really don't give a shit about these formats, other than having to
handle them. It's notable that AV_PIX_FMT_MONOBLACK (also 1 bit gray,
just packed) already explicitly marked itself as RGB.
2020-04-23 10:47:13 +00:00
|
|
|
|
2020-05-20 16:25:14 +00:00
|
|
|
#define FLOAT_YUV(def, dname, xs, ys, a) \
|
2020-05-09 15:58:55 +00:00
|
|
|
[def - IMGFMT_CUST_BASE] = { \
|
|
|
|
.name = dname, \
|
2020-05-20 16:25:14 +00:00
|
|
|
.desc = { .flags = MP_IMGFLAG_COLOR_YUV | MP_IMGFLAG_TYPE_FLOAT, \
|
|
|
|
.chroma_xs = xs, .chroma_ys = ys, \
|
|
|
|
.comps = { {0, 0, 32}, {1, 0, 32}, {2, 0, 32}, \
|
|
|
|
{3 * (a), 0, 32 * (a)} }, }}
|
2020-05-09 15:58:55 +00:00
|
|
|
|
2014-04-14 18:19:44 +00:00
|
|
|
static const struct mp_imgfmt_entry mp_imgfmt_list[] = {
|
2014-05-22 18:55:17 +00:00
|
|
|
// not in ffmpeg
|
2020-04-21 20:56:45 +00:00
|
|
|
[IMGFMT_VDPAU_OUTPUT - IMGFMT_CUST_BASE] = {
|
|
|
|
.name = "vdpau_output",
|
|
|
|
.desc = {
|
2020-05-20 16:25:14 +00:00
|
|
|
.flags = MP_IMGFLAG_NE | MP_IMGFLAG_RGB | MP_IMGFLAG_HWACCEL,
|
2020-04-21 20:56:45 +00:00
|
|
|
},
|
|
|
|
},
|
|
|
|
[IMGFMT_RGB30 - IMGFMT_CUST_BASE] = {
|
|
|
|
.name = "rgb30",
|
|
|
|
.desc = {
|
2020-05-20 16:25:14 +00:00
|
|
|
.flags = MP_IMGFLAG_RGB,
|
2020-05-19 21:58:36 +00:00
|
|
|
.comps = { {0, 20, 10}, {0, 10, 10}, {0, 0, 10} },
|
2020-04-21 20:56:45 +00:00
|
|
|
},
|
|
|
|
},
|
|
|
|
[IMGFMT_YAP8 - IMGFMT_CUST_BASE] = {
|
|
|
|
.name = "yap8",
|
2020-05-20 16:25:14 +00:00
|
|
|
.desc = {
|
|
|
|
.flags = MP_IMGFLAG_COLOR_YUV,
|
|
|
|
.comps = { {0, 0, 8}, {0}, {0}, {1, 0, 8} },
|
2020-04-21 20:56:45 +00:00
|
|
|
},
|
|
|
|
},
|
|
|
|
[IMGFMT_YAP16 - IMGFMT_CUST_BASE] = {
|
|
|
|
.name = "yap16",
|
2020-05-20 16:25:14 +00:00
|
|
|
.desc = {
|
|
|
|
.flags = MP_IMGFLAG_COLOR_YUV,
|
|
|
|
.comps = { {0, 0, 16}, {0}, {0}, {1, 0, 16} },
|
2020-04-21 20:56:45 +00:00
|
|
|
},
|
|
|
|
},
|
img_format: add some mpv-only helper formats
Utterly useless, but the intention is to make dealing with corner case
pixel formats (forced upon us by FFmpeg, very rarely) less of a pain.
The zimg wrapper will use them. (It already supports these formats
automatically, but it will help with its internals.)
Y1 is considered RGB, even though gray formats are generally treated as
YUV for various reasons. mpv will default all YUV formats to limited
range internally, which makes no sense for a 1 bit format, so this is a
problem. I wanted to avoid that mp_image_params_guess_csp() (which
applies the default) explicitly checks for an image format, so although
a bit janky, this seems to be a good solution, especially because I
really don't give a shit about these formats, other than having to
handle them. It's notable that AV_PIX_FMT_MONOBLACK (also 1 bit gray,
just packed) already explicitly marked itself as RGB.
2020-04-23 10:47:13 +00:00
|
|
|
[IMGFMT_Y1 - IMGFMT_CUST_BASE] = {
|
|
|
|
.name = "y1",
|
2020-05-20 16:25:14 +00:00
|
|
|
.desc = {
|
|
|
|
.flags = MP_IMGFLAG_COLOR_RGB,
|
|
|
|
.comps = { {0, 0, 8, -7} },
|
img_format: add some mpv-only helper formats
Utterly useless, but the intention is to make dealing with corner case
pixel formats (forced upon us by FFmpeg, very rarely) less of a pain.
The zimg wrapper will use them. (It already supports these formats
automatically, but it will help with its internals.)
Y1 is considered RGB, even though gray formats are generally treated as
YUV for various reasons. mpv will default all YUV formats to limited
range internally, which makes no sense for a 1 bit format, so this is a
problem. I wanted to avoid that mp_image_params_guess_csp() (which
applies the default) explicitly checks for an image format, so although
a bit janky, this seems to be a good solution, especially because I
really don't give a shit about these formats, other than having to
handle them. It's notable that AV_PIX_FMT_MONOBLACK (also 1 bit gray,
just packed) already explicitly marked itself as RGB.
2020-04-23 10:47:13 +00:00
|
|
|
},
|
|
|
|
},
|
2020-05-09 15:58:55 +00:00
|
|
|
[IMGFMT_YAPF - IMGFMT_CUST_BASE] = {
|
|
|
|
.name = "grayaf32", // try to mimic ffmpeg naming convention
|
2020-05-20 16:25:14 +00:00
|
|
|
.desc = {
|
|
|
|
.flags = MP_IMGFLAG_COLOR_YUV | MP_IMGFLAG_TYPE_FLOAT,
|
|
|
|
.comps = { {0, 0, 32}, {0}, {0}, {1, 0, 32} },
|
2020-05-09 15:58:55 +00:00
|
|
|
},
|
|
|
|
},
|
2020-05-20 16:25:14 +00:00
|
|
|
FLOAT_YUV(IMGFMT_444PF, "yuv444pf", 0, 0, 0),
|
|
|
|
FLOAT_YUV(IMGFMT_444APF, "yuva444pf", 0, 0, 1),
|
|
|
|
FLOAT_YUV(IMGFMT_420PF, "yuv420pf", 1, 1, 0),
|
|
|
|
FLOAT_YUV(IMGFMT_420APF, "yuva420pf", 1, 1, 1),
|
|
|
|
FLOAT_YUV(IMGFMT_422PF, "yuv422pf", 1, 0, 0),
|
|
|
|
FLOAT_YUV(IMGFMT_422APF, "yuva422pf", 1, 0, 1),
|
|
|
|
FLOAT_YUV(IMGFMT_440PF, "yuv440pf", 0, 1, 0),
|
|
|
|
FLOAT_YUV(IMGFMT_440APF, "yuva440pf", 0, 1, 1),
|
|
|
|
FLOAT_YUV(IMGFMT_410PF, "yuv410pf", 2, 2, 0),
|
|
|
|
FLOAT_YUV(IMGFMT_410APF, "yuva410pf", 2, 2, 1),
|
|
|
|
FLOAT_YUV(IMGFMT_411PF, "yuv411pf", 2, 0, 0),
|
|
|
|
FLOAT_YUV(IMGFMT_411APF, "yuva411pf", 2, 0, 1),
|
img_format: add some mpv-only helper formats
Utterly useless, but the intention is to make dealing with corner case
pixel formats (forced upon us by FFmpeg, very rarely) less of a pain.
The zimg wrapper will use them. (It already supports these formats
automatically, but it will help with its internals.)
Y1 is considered RGB, even though gray formats are generally treated as
YUV for various reasons. mpv will default all YUV formats to limited
range internally, which makes no sense for a 1 bit format, so this is a
problem. I wanted to avoid that mp_image_params_guess_csp() (which
applies the default) explicitly checks for an image format, so although
a bit janky, this seems to be a good solution, especially because I
really don't give a shit about these formats, other than having to
handle them. It's notable that AV_PIX_FMT_MONOBLACK (also 1 bit gray,
just packed) already explicitly marked itself as RGB.
2020-04-23 10:47:13 +00:00
|
|
|
FRINGE_GBRP(IMGFMT_GBRP1, "gbrp1", 1),
|
|
|
|
FRINGE_GBRP(IMGFMT_GBRP2, "gbrp2", 2),
|
|
|
|
FRINGE_GBRP(IMGFMT_GBRP3, "gbrp3", 3),
|
|
|
|
FRINGE_GBRP(IMGFMT_GBRP4, "gbrp4", 4),
|
|
|
|
FRINGE_GBRP(IMGFMT_GBRP5, "gbrp5", 5),
|
|
|
|
FRINGE_GBRP(IMGFMT_GBRP6, "gbrp6", 6),
|
2020-04-21 20:56:45 +00:00
|
|
|
// in FFmpeg, but FFmpeg names have an annoying "_vld" suffix
|
|
|
|
[IMGFMT_VIDEOTOOLBOX - IMGFMT_CUST_BASE] = {
|
|
|
|
.name = "videotoolbox",
|
|
|
|
},
|
|
|
|
[IMGFMT_VAAPI - IMGFMT_CUST_BASE] = {
|
|
|
|
.name = "vaapi",
|
|
|
|
},
|
2012-08-21 17:20:36 +00:00
|
|
|
};
|
|
|
|
|
2020-04-21 20:56:45 +00:00
|
|
|
static const struct mp_imgfmt_entry *get_mp_desc(int imgfmt)
|
|
|
|
{
|
|
|
|
if (imgfmt < IMGFMT_CUST_BASE)
|
|
|
|
return NULL;
|
|
|
|
int index = imgfmt - IMGFMT_CUST_BASE;
|
|
|
|
if (index >= MP_ARRAY_SIZE(mp_imgfmt_list))
|
|
|
|
return NULL;
|
|
|
|
const struct mp_imgfmt_entry *e = &mp_imgfmt_list[index];
|
|
|
|
return e->name ? e : NULL;
|
|
|
|
}
|
|
|
|
|
2014-04-14 18:19:44 +00:00
|
|
|
char **mp_imgfmt_name_list(void)
|
|
|
|
{
|
|
|
|
int count = IMGFMT_END - IMGFMT_START;
|
|
|
|
char **list = talloc_zero_array(NULL, char *, count + 1);
|
|
|
|
int num = 0;
|
|
|
|
for (int n = IMGFMT_START; n < IMGFMT_END; n++) {
|
|
|
|
const char *name = mp_imgfmt_to_name(n);
|
2017-06-18 11:46:34 +00:00
|
|
|
if (strcmp(name, "unknown") != 0)
|
2014-06-14 07:58:48 +00:00
|
|
|
list[num++] = talloc_strdup(list, name);
|
2014-04-14 18:19:44 +00:00
|
|
|
}
|
|
|
|
return list;
|
|
|
|
}
|
|
|
|
|
2017-06-18 11:58:42 +00:00
|
|
|
int mp_imgfmt_from_name(bstr name)
|
2012-08-21 17:20:36 +00:00
|
|
|
{
|
2020-04-21 20:56:45 +00:00
|
|
|
if (bstr_equals0(name, "none"))
|
|
|
|
return 0;
|
|
|
|
for (int n = 0; n < MP_ARRAY_SIZE(mp_imgfmt_list); n++) {
|
|
|
|
const struct mp_imgfmt_entry *p = &mp_imgfmt_list[n];
|
|
|
|
if (p->name && bstr_equals0(name, p->name))
|
|
|
|
return IMGFMT_CUST_BASE + n;
|
2013-01-17 15:10:26 +00:00
|
|
|
}
|
2020-04-21 20:56:45 +00:00
|
|
|
return pixfmt2imgfmt(av_get_pix_fmt(mp_tprintf(80, "%.*s", BSTR_P(name))));
|
2012-08-21 17:20:36 +00:00
|
|
|
}
|
|
|
|
|
2014-06-14 07:58:48 +00:00
|
|
|
char *mp_imgfmt_to_name_buf(char *buf, size_t buf_size, int fmt)
|
2012-08-21 17:20:36 +00:00
|
|
|
{
|
2020-04-21 20:56:45 +00:00
|
|
|
const struct mp_imgfmt_entry *p = get_mp_desc(fmt);
|
|
|
|
const char *name = p ? p->name : NULL;
|
2014-06-14 07:58:48 +00:00
|
|
|
if (!name) {
|
|
|
|
const AVPixFmtDescriptor *pixdesc = av_pix_fmt_desc_get(imgfmt2pixfmt(fmt));
|
|
|
|
if (pixdesc)
|
|
|
|
name = pixdesc->name;
|
2012-08-21 17:20:36 +00:00
|
|
|
}
|
2014-06-14 07:58:48 +00:00
|
|
|
if (!name)
|
|
|
|
name = "unknown";
|
|
|
|
snprintf(buf, buf_size, "%s", name);
|
|
|
|
int len = strlen(buf);
|
|
|
|
if (len > 2 && buf[len - 2] == MP_SELECT_LE_BE('l', 'b') && buf[len - 1] == 'e')
|
|
|
|
buf[len - 2] = '\0';
|
|
|
|
return buf;
|
2012-08-21 17:20:36 +00:00
|
|
|
}
|
2012-12-31 00:58:25 +00:00
|
|
|
|
2020-05-19 21:58:36 +00:00
|
|
|
static void fill_pixdesc_layout(struct mp_imgfmt_desc *desc,
|
|
|
|
enum AVPixelFormat fmt,
|
|
|
|
const AVPixFmtDescriptor *pd)
|
video: add pixel component location metadata
I thought I'd probably want something like this, so the hardcoded stuff
in repack.c can be removed eventually. Of course this has no purpose at
all, and will not have any. (For now, this provides only metadata, and
nothing uses it, apart from the "test" that dumps it as text.)
This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite,
because the format is 100% useless). Support for some mpv-only formats
is missing, ironically.
The code goes through _lengths_ to try to make sense out of the FFmpeg
AVPixFmtDescriptor data. Which is even more amazing that the new
metadata basically mirrors pixdesc, and just adds to it. Considering
code complexity and speed issues (it takes time to crunch through all
this shit all the time), and especially the fact that pixdesc is very
_incomplete_, it would probably better to have our own table to all
formats. But then we'd not scramble every time FFmpeg adds a new format,
which would be annoying. On the other hand, by using pixdesc, we get the
excitement to see whether this code will work, or break everything in
catastrophic ways.
The data structure still sucks a lot. Maybe I'll redo it again. The text
dump is weirdly differently formatted than the C struct - because I'm
not happy with the representation. Maybe I'll redo it all over again.
In summary: this commit does nothing.
2020-05-17 22:24:31 +00:00
|
|
|
{
|
2020-05-19 21:58:36 +00:00
|
|
|
if (pd->flags & AV_PIX_FMT_FLAG_PAL ||
|
|
|
|
pd->flags & AV_PIX_FMT_FLAG_HWACCEL)
|
video: add pixel component location metadata
I thought I'd probably want something like this, so the hardcoded stuff
in repack.c can be removed eventually. Of course this has no purpose at
all, and will not have any. (For now, this provides only metadata, and
nothing uses it, apart from the "test" that dumps it as text.)
This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite,
because the format is 100% useless). Support for some mpv-only formats
is missing, ironically.
The code goes through _lengths_ to try to make sense out of the FFmpeg
AVPixFmtDescriptor data. Which is even more amazing that the new
metadata basically mirrors pixdesc, and just adds to it. Considering
code complexity and speed issues (it takes time to crunch through all
this shit all the time), and especially the fact that pixdesc is very
_incomplete_, it would probably better to have our own table to all
formats. But then we'd not scramble every time FFmpeg adds a new format,
which would be annoying. On the other hand, by using pixdesc, we get the
excitement to see whether this code will work, or break everything in
catastrophic ways.
The data structure still sucks a lot. Maybe I'll redo it again. The text
dump is weirdly differently formatted than the C struct - because I'm
not happy with the representation. Maybe I'll redo it all over again.
In summary: this commit does nothing.
2020-05-17 22:24:31 +00:00
|
|
|
goto fail;
|
|
|
|
|
|
|
|
bool has_alpha = pd->flags & AV_PIX_FMT_FLAG_ALPHA;
|
|
|
|
if (pd->nb_components != 1 + has_alpha &&
|
|
|
|
pd->nb_components != 3 + has_alpha)
|
|
|
|
goto fail;
|
|
|
|
|
|
|
|
// Very convenient: we assume we're always on little endian, and FFmpeg
|
|
|
|
// explicitly marks big endian formats => don't need to guess whether a
|
|
|
|
// format is little endian, or not affected by byte order.
|
|
|
|
bool is_be = pd->flags & AV_PIX_FMT_FLAG_BE;
|
|
|
|
|
|
|
|
// Packed sub-sampled YUV is very... special.
|
|
|
|
bool is_packed_ss_yuv = pd->log2_chroma_w && !pd->log2_chroma_h &&
|
|
|
|
pd->comp[1].plane == 0 && pd->comp[2].plane == 0 &&
|
|
|
|
pd->nb_components == 3;
|
|
|
|
|
2020-05-19 21:58:36 +00:00
|
|
|
if (is_packed_ss_yuv)
|
|
|
|
desc->bpp[0] = pd->comp[1].step * 8;
|
video: add pixel component location metadata
I thought I'd probably want something like this, so the hardcoded stuff
in repack.c can be removed eventually. Of course this has no purpose at
all, and will not have any. (For now, this provides only metadata, and
nothing uses it, apart from the "test" that dumps it as text.)
This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite,
because the format is 100% useless). Support for some mpv-only formats
is missing, ironically.
The code goes through _lengths_ to try to make sense out of the FFmpeg
AVPixFmtDescriptor data. Which is even more amazing that the new
metadata basically mirrors pixdesc, and just adds to it. Considering
code complexity and speed issues (it takes time to crunch through all
this shit all the time), and especially the fact that pixdesc is very
_incomplete_, it would probably better to have our own table to all
formats. But then we'd not scramble every time FFmpeg adds a new format,
which would be annoying. On the other hand, by using pixdesc, we get the
excitement to see whether this code will work, or break everything in
catastrophic ways.
The data structure still sucks a lot. Maybe I'll redo it again. The text
dump is weirdly differently formatted than the C struct - because I'm
not happy with the representation. Maybe I'll redo it all over again.
In summary: this commit does nothing.
2020-05-17 22:24:31 +00:00
|
|
|
|
|
|
|
int el_bits = (pd->flags & AV_PIX_FMT_FLAG_BITSTREAM) ? 1 : 8;
|
|
|
|
for (int c = 0; c < pd->nb_components; c++) {
|
|
|
|
const AVComponentDescriptor *d = &pd->comp[c];
|
|
|
|
if (d->plane >= MP_MAX_PLANES)
|
|
|
|
goto fail;
|
|
|
|
|
2020-05-20 16:25:14 +00:00
|
|
|
desc->num_planes = MPMAX(desc->num_planes, d->plane + 1);
|
video: add pixel component location metadata
I thought I'd probably want something like this, so the hardcoded stuff
in repack.c can be removed eventually. Of course this has no purpose at
all, and will not have any. (For now, this provides only metadata, and
nothing uses it, apart from the "test" that dumps it as text.)
This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite,
because the format is 100% useless). Support for some mpv-only formats
is missing, ironically.
The code goes through _lengths_ to try to make sense out of the FFmpeg
AVPixFmtDescriptor data. Which is even more amazing that the new
metadata basically mirrors pixdesc, and just adds to it. Considering
code complexity and speed issues (it takes time to crunch through all
this shit all the time), and especially the fact that pixdesc is very
_incomplete_, it would probably better to have our own table to all
formats. But then we'd not scramble every time FFmpeg adds a new format,
which would be annoying. On the other hand, by using pixdesc, we get the
excitement to see whether this code will work, or break everything in
catastrophic ways.
The data structure still sucks a lot. Maybe I'll redo it again. The text
dump is weirdly differently formatted than the C struct - because I'm
not happy with the representation. Maybe I'll redo it all over again.
In summary: this commit does nothing.
2020-05-17 22:24:31 +00:00
|
|
|
|
2020-05-19 21:58:36 +00:00
|
|
|
int plane_bits = desc->bpp[d->plane];
|
video: add pixel component location metadata
I thought I'd probably want something like this, so the hardcoded stuff
in repack.c can be removed eventually. Of course this has no purpose at
all, and will not have any. (For now, this provides only metadata, and
nothing uses it, apart from the "test" that dumps it as text.)
This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite,
because the format is 100% useless). Support for some mpv-only formats
is missing, ironically.
The code goes through _lengths_ to try to make sense out of the FFmpeg
AVPixFmtDescriptor data. Which is even more amazing that the new
metadata basically mirrors pixdesc, and just adds to it. Considering
code complexity and speed issues (it takes time to crunch through all
this shit all the time), and especially the fact that pixdesc is very
_incomplete_, it would probably better to have our own table to all
formats. But then we'd not scramble every time FFmpeg adds a new format,
which would be annoying. On the other hand, by using pixdesc, we get the
excitement to see whether this code will work, or break everything in
catastrophic ways.
The data structure still sucks a lot. Maybe I'll redo it again. The text
dump is weirdly differently formatted than the C struct - because I'm
not happy with the representation. Maybe I'll redo it all over again.
In summary: this commit does nothing.
2020-05-17 22:24:31 +00:00
|
|
|
int c_bits = d->step * el_bits;
|
|
|
|
|
|
|
|
// The first component wins, because either all components result in
|
|
|
|
// the same value, or luma wins (luma always comes before chroma).
|
|
|
|
if (plane_bits) {
|
|
|
|
if (c_bits > plane_bits)
|
|
|
|
goto fail; // inconsistent
|
|
|
|
} else {
|
2020-05-19 21:58:36 +00:00
|
|
|
desc->bpp[d->plane] = plane_bits = c_bits;
|
video: add pixel component location metadata
I thought I'd probably want something like this, so the hardcoded stuff
in repack.c can be removed eventually. Of course this has no purpose at
all, and will not have any. (For now, this provides only metadata, and
nothing uses it, apart from the "test" that dumps it as text.)
This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite,
because the format is 100% useless). Support for some mpv-only formats
is missing, ironically.
The code goes through _lengths_ to try to make sense out of the FFmpeg
AVPixFmtDescriptor data. Which is even more amazing that the new
metadata basically mirrors pixdesc, and just adds to it. Considering
code complexity and speed issues (it takes time to crunch through all
this shit all the time), and especially the fact that pixdesc is very
_incomplete_, it would probably better to have our own table to all
formats. But then we'd not scramble every time FFmpeg adds a new format,
which would be annoying. On the other hand, by using pixdesc, we get the
excitement to see whether this code will work, or break everything in
catastrophic ways.
The data structure still sucks a lot. Maybe I'll redo it again. The text
dump is weirdly differently formatted than the C struct - because I'm
not happy with the representation. Maybe I'll redo it all over again.
In summary: this commit does nothing.
2020-05-17 22:24:31 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
int shift = d->shift;
|
|
|
|
// What the fuck: for some inexplicable reason, MONOB uses shift=7
|
|
|
|
// in pixdesc, which is basically out of bounds. Pixdesc bug?
|
|
|
|
// Make it behave like MONOW. (No, the bit-order is not different.)
|
|
|
|
if (fmt == AV_PIX_FMT_MONOBLACK)
|
|
|
|
shift = 0;
|
|
|
|
|
|
|
|
int offset = d->offset * el_bits;
|
|
|
|
// The pixdesc logic for reading and endian swapping is as follows
|
|
|
|
// (reverse engineered from av_read_image_line2()):
|
|
|
|
// - determine a word size that will include the component fully;
|
|
|
|
// this includes the "active" bits and the amount "shifted" away
|
|
|
|
// (for example shift=7/depth=18 => 32 bit word reading [31:0])
|
|
|
|
// - the same format can use different word sizes (e.g. bgr565: the R
|
|
|
|
// component at offset 0 is read as 8 bit; BG is read as 16 bits)
|
|
|
|
// - if BE flag is set, swap the word before proceeding
|
|
|
|
// - extract via shift and mask derived by depth
|
|
|
|
int word = mp_round_next_power_of_2(MPMAX(d->depth + shift, 8)) / 8;
|
|
|
|
// The purpose of this is unknown. It's an absurdity fished out of
|
|
|
|
// av_read_image_line2()'s implementation. It seems technically
|
|
|
|
// unnecessary, and provides no information. On the other hand, it
|
|
|
|
// compensates for seemingly bogus packed integer pixdescs; this
|
|
|
|
// is "why" some formats use d->offset = -1.
|
|
|
|
if (is_be && el_bits == 8 && word == 1)
|
|
|
|
offset += 8;
|
|
|
|
// Pixdesc's model requires accesses with varying word-sizes. This
|
|
|
|
// is complete bullshit, so we transform it into word swaps before
|
|
|
|
// further processing.
|
|
|
|
if (is_be && word == 1) {
|
|
|
|
// Probably packed RGB formats with varying word sizes. Assume
|
|
|
|
// the word access size is the entire pixel.
|
2020-05-19 21:58:36 +00:00
|
|
|
int logend = mp_log2(plane_bits) - 3;
|
|
|
|
if (!MP_IS_POWER_OF_2(plane_bits) || logend < 0 || logend > 3)
|
video: add pixel component location metadata
I thought I'd probably want something like this, so the hardcoded stuff
in repack.c can be removed eventually. Of course this has no purpose at
all, and will not have any. (For now, this provides only metadata, and
nothing uses it, apart from the "test" that dumps it as text.)
This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite,
because the format is 100% useless). Support for some mpv-only formats
is missing, ironically.
The code goes through _lengths_ to try to make sense out of the FFmpeg
AVPixFmtDescriptor data. Which is even more amazing that the new
metadata basically mirrors pixdesc, and just adds to it. Considering
code complexity and speed issues (it takes time to crunch through all
this shit all the time), and especially the fact that pixdesc is very
_incomplete_, it would probably better to have our own table to all
formats. But then we'd not scramble every time FFmpeg adds a new format,
which would be annoying. On the other hand, by using pixdesc, we get the
excitement to see whether this code will work, or break everything in
catastrophic ways.
The data structure still sucks a lot. Maybe I'll redo it again. The text
dump is weirdly differently formatted than the C struct - because I'm
not happy with the representation. Maybe I'll redo it all over again.
In summary: this commit does nothing.
2020-05-17 22:24:31 +00:00
|
|
|
goto fail;
|
2020-05-19 21:58:36 +00:00
|
|
|
if (!desc->endian_shift)
|
|
|
|
desc->endian_shift = logend;
|
|
|
|
if (desc->endian_shift != logend)
|
video: add pixel component location metadata
I thought I'd probably want something like this, so the hardcoded stuff
in repack.c can be removed eventually. Of course this has no purpose at
all, and will not have any. (For now, this provides only metadata, and
nothing uses it, apart from the "test" that dumps it as text.)
This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite,
because the format is 100% useless). Support for some mpv-only formats
is missing, ironically.
The code goes through _lengths_ to try to make sense out of the FFmpeg
AVPixFmtDescriptor data. Which is even more amazing that the new
metadata basically mirrors pixdesc, and just adds to it. Considering
code complexity and speed issues (it takes time to crunch through all
this shit all the time), and especially the fact that pixdesc is very
_incomplete_, it would probably better to have our own table to all
formats. But then we'd not scramble every time FFmpeg adds a new format,
which would be annoying. On the other hand, by using pixdesc, we get the
excitement to see whether this code will work, or break everything in
catastrophic ways.
The data structure still sucks a lot. Maybe I'll redo it again. The text
dump is weirdly differently formatted than the C struct - because I'm
not happy with the representation. Maybe I'll redo it all over again.
In summary: this commit does nothing.
2020-05-17 22:24:31 +00:00
|
|
|
goto fail;
|
2020-05-19 21:58:36 +00:00
|
|
|
offset = (1 << desc->endian_shift) * 8 - 8 - offset;
|
video: add pixel component location metadata
I thought I'd probably want something like this, so the hardcoded stuff
in repack.c can be removed eventually. Of course this has no purpose at
all, and will not have any. (For now, this provides only metadata, and
nothing uses it, apart from the "test" that dumps it as text.)
This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite,
because the format is 100% useless). Support for some mpv-only formats
is missing, ironically.
The code goes through _lengths_ to try to make sense out of the FFmpeg
AVPixFmtDescriptor data. Which is even more amazing that the new
metadata basically mirrors pixdesc, and just adds to it. Considering
code complexity and speed issues (it takes time to crunch through all
this shit all the time), and especially the fact that pixdesc is very
_incomplete_, it would probably better to have our own table to all
formats. But then we'd not scramble every time FFmpeg adds a new format,
which would be annoying. On the other hand, by using pixdesc, we get the
excitement to see whether this code will work, or break everything in
catastrophic ways.
The data structure still sucks a lot. Maybe I'll redo it again. The text
dump is weirdly differently formatted than the C struct - because I'm
not happy with the representation. Maybe I'll redo it all over again.
In summary: this commit does nothing.
2020-05-17 22:24:31 +00:00
|
|
|
}
|
|
|
|
if (is_be && word > 1) {
|
2020-05-19 21:58:36 +00:00
|
|
|
int logend = mp_log2(word);
|
|
|
|
if (desc->endian_shift && desc->endian_shift != logend)
|
video: add pixel component location metadata
I thought I'd probably want something like this, so the hardcoded stuff
in repack.c can be removed eventually. Of course this has no purpose at
all, and will not have any. (For now, this provides only metadata, and
nothing uses it, apart from the "test" that dumps it as text.)
This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite,
because the format is 100% useless). Support for some mpv-only formats
is missing, ironically.
The code goes through _lengths_ to try to make sense out of the FFmpeg
AVPixFmtDescriptor data. Which is even more amazing that the new
metadata basically mirrors pixdesc, and just adds to it. Considering
code complexity and speed issues (it takes time to crunch through all
this shit all the time), and especially the fact that pixdesc is very
_incomplete_, it would probably better to have our own table to all
formats. But then we'd not scramble every time FFmpeg adds a new format,
which would be annoying. On the other hand, by using pixdesc, we get the
excitement to see whether this code will work, or break everything in
catastrophic ways.
The data structure still sucks a lot. Maybe I'll redo it again. The text
dump is weirdly differently formatted than the C struct - because I'm
not happy with the representation. Maybe I'll redo it all over again.
In summary: this commit does nothing.
2020-05-17 22:24:31 +00:00
|
|
|
goto fail; // fortunately not needed/never happens
|
2020-05-19 21:58:36 +00:00
|
|
|
if (logend > 3)
|
video: add pixel component location metadata
I thought I'd probably want something like this, so the hardcoded stuff
in repack.c can be removed eventually. Of course this has no purpose at
all, and will not have any. (For now, this provides only metadata, and
nothing uses it, apart from the "test" that dumps it as text.)
This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite,
because the format is 100% useless). Support for some mpv-only formats
is missing, ironically.
The code goes through _lengths_ to try to make sense out of the FFmpeg
AVPixFmtDescriptor data. Which is even more amazing that the new
metadata basically mirrors pixdesc, and just adds to it. Considering
code complexity and speed issues (it takes time to crunch through all
this shit all the time), and especially the fact that pixdesc is very
_incomplete_, it would probably better to have our own table to all
formats. But then we'd not scramble every time FFmpeg adds a new format,
which would be annoying. On the other hand, by using pixdesc, we get the
excitement to see whether this code will work, or break everything in
catastrophic ways.
The data structure still sucks a lot. Maybe I'll redo it again. The text
dump is weirdly differently formatted than the C struct - because I'm
not happy with the representation. Maybe I'll redo it all over again.
In summary: this commit does nothing.
2020-05-17 22:24:31 +00:00
|
|
|
goto fail;
|
2020-05-19 21:58:36 +00:00
|
|
|
desc->endian_shift = logend;
|
video: add pixel component location metadata
I thought I'd probably want something like this, so the hardcoded stuff
in repack.c can be removed eventually. Of course this has no purpose at
all, and will not have any. (For now, this provides only metadata, and
nothing uses it, apart from the "test" that dumps it as text.)
This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite,
because the format is 100% useless). Support for some mpv-only formats
is missing, ironically.
The code goes through _lengths_ to try to make sense out of the FFmpeg
AVPixFmtDescriptor data. Which is even more amazing that the new
metadata basically mirrors pixdesc, and just adds to it. Considering
code complexity and speed issues (it takes time to crunch through all
this shit all the time), and especially the fact that pixdesc is very
_incomplete_, it would probably better to have our own table to all
formats. But then we'd not scramble every time FFmpeg adds a new format,
which would be annoying. On the other hand, by using pixdesc, we get the
excitement to see whether this code will work, or break everything in
catastrophic ways.
The data structure still sucks a lot. Maybe I'll redo it again. The text
dump is weirdly differently formatted than the C struct - because I'm
not happy with the representation. Maybe I'll redo it all over again.
In summary: this commit does nothing.
2020-05-17 22:24:31 +00:00
|
|
|
}
|
2020-05-19 21:58:36 +00:00
|
|
|
|
video: add pixel component location metadata
I thought I'd probably want something like this, so the hardcoded stuff
in repack.c can be removed eventually. Of course this has no purpose at
all, and will not have any. (For now, this provides only metadata, and
nothing uses it, apart from the "test" that dumps it as text.)
This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite,
because the format is 100% useless). Support for some mpv-only formats
is missing, ironically.
The code goes through _lengths_ to try to make sense out of the FFmpeg
AVPixFmtDescriptor data. Which is even more amazing that the new
metadata basically mirrors pixdesc, and just adds to it. Considering
code complexity and speed issues (it takes time to crunch through all
this shit all the time), and especially the fact that pixdesc is very
_incomplete_, it would probably better to have our own table to all
formats. But then we'd not scramble every time FFmpeg adds a new format,
which would be annoying. On the other hand, by using pixdesc, we get the
excitement to see whether this code will work, or break everything in
catastrophic ways.
The data structure still sucks a lot. Maybe I'll redo it again. The text
dump is weirdly differently formatted than the C struct - because I'm
not happy with the representation. Maybe I'll redo it all over again.
In summary: this commit does nothing.
2020-05-17 22:24:31 +00:00
|
|
|
// We always use bit offsets; this doesn't lose any information,
|
|
|
|
// and pixdesc is merely more redundant.
|
|
|
|
offset += shift;
|
|
|
|
if (offset < 0 || offset >= (1 << 6))
|
|
|
|
goto fail;
|
|
|
|
if (offset + d->depth > plane_bits)
|
|
|
|
goto fail;
|
|
|
|
if (d->depth < 0 || d->depth >= (1 << 6))
|
|
|
|
goto fail;
|
2020-05-19 21:58:36 +00:00
|
|
|
desc->comps[c] = (struct mp_imgfmt_comp_desc){
|
video: add pixel component location metadata
I thought I'd probably want something like this, so the hardcoded stuff
in repack.c can be removed eventually. Of course this has no purpose at
all, and will not have any. (For now, this provides only metadata, and
nothing uses it, apart from the "test" that dumps it as text.)
This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite,
because the format is 100% useless). Support for some mpv-only formats
is missing, ironically.
The code goes through _lengths_ to try to make sense out of the FFmpeg
AVPixFmtDescriptor data. Which is even more amazing that the new
metadata basically mirrors pixdesc, and just adds to it. Considering
code complexity and speed issues (it takes time to crunch through all
this shit all the time), and especially the fact that pixdesc is very
_incomplete_, it would probably better to have our own table to all
formats. But then we'd not scramble every time FFmpeg adds a new format,
which would be annoying. On the other hand, by using pixdesc, we get the
excitement to see whether this code will work, or break everything in
catastrophic ways.
The data structure still sucks a lot. Maybe I'll redo it again. The text
dump is weirdly differently formatted than the C struct - because I'm
not happy with the representation. Maybe I'll redo it all over again.
In summary: this commit does nothing.
2020-05-17 22:24:31 +00:00
|
|
|
.plane = d->plane,
|
|
|
|
.offset = offset,
|
|
|
|
.size = d->depth,
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
2020-05-20 16:25:14 +00:00
|
|
|
for (int p = 0; p < desc->num_planes; p++) {
|
2020-05-19 21:58:36 +00:00
|
|
|
if (!desc->bpp[p])
|
video: add pixel component location metadata
I thought I'd probably want something like this, so the hardcoded stuff
in repack.c can be removed eventually. Of course this has no purpose at
all, and will not have any. (For now, this provides only metadata, and
nothing uses it, apart from the "test" that dumps it as text.)
This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite,
because the format is 100% useless). Support for some mpv-only formats
is missing, ironically.
The code goes through _lengths_ to try to make sense out of the FFmpeg
AVPixFmtDescriptor data. Which is even more amazing that the new
metadata basically mirrors pixdesc, and just adds to it. Considering
code complexity and speed issues (it takes time to crunch through all
this shit all the time), and especially the fact that pixdesc is very
_incomplete_, it would probably better to have our own table to all
formats. But then we'd not scramble every time FFmpeg adds a new format,
which would be annoying. On the other hand, by using pixdesc, we get the
excitement to see whether this code will work, or break everything in
catastrophic ways.
The data structure still sucks a lot. Maybe I'll redo it again. The text
dump is weirdly differently formatted than the C struct - because I'm
not happy with the representation. Maybe I'll redo it all over again.
In summary: this commit does nothing.
2020-05-17 22:24:31 +00:00
|
|
|
goto fail; // plane doesn't exist
|
|
|
|
}
|
|
|
|
|
|
|
|
// What the fuck: this is probably a pixdesc bug, so fix it.
|
|
|
|
if (fmt == AV_PIX_FMT_RGB8) {
|
2020-05-19 21:58:36 +00:00
|
|
|
desc->comps[2] = (struct mp_imgfmt_comp_desc){0, 0, 2};
|
|
|
|
desc->comps[1] = (struct mp_imgfmt_comp_desc){0, 2, 3};
|
|
|
|
desc->comps[0] = (struct mp_imgfmt_comp_desc){0, 5, 3};
|
video: add pixel component location metadata
I thought I'd probably want something like this, so the hardcoded stuff
in repack.c can be removed eventually. Of course this has no purpose at
all, and will not have any. (For now, this provides only metadata, and
nothing uses it, apart from the "test" that dumps it as text.)
This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite,
because the format is 100% useless). Support for some mpv-only formats
is missing, ironically.
The code goes through _lengths_ to try to make sense out of the FFmpeg
AVPixFmtDescriptor data. Which is even more amazing that the new
metadata basically mirrors pixdesc, and just adds to it. Considering
code complexity and speed issues (it takes time to crunch through all
this shit all the time), and especially the fact that pixdesc is very
_incomplete_, it would probably better to have our own table to all
formats. But then we'd not scramble every time FFmpeg adds a new format,
which would be annoying. On the other hand, by using pixdesc, we get the
excitement to see whether this code will work, or break everything in
catastrophic ways.
The data structure still sucks a lot. Maybe I'll redo it again. The text
dump is weirdly differently formatted than the C struct - because I'm
not happy with the representation. Maybe I'll redo it all over again.
In summary: this commit does nothing.
2020-05-17 22:24:31 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// Overlap test. If any shared bits are happening, this is not a format we
|
|
|
|
// can represent (or it's something like Bayer: components in the same bits,
|
|
|
|
// but different alternating lines).
|
|
|
|
bool any_shared_bits = false;
|
|
|
|
bool any_shared_bytes = false;
|
|
|
|
for (int c = 0; c < pd->nb_components; c++) {
|
|
|
|
for (int i = 0; i < c; i++) {
|
2020-05-19 21:58:36 +00:00
|
|
|
struct mp_imgfmt_comp_desc *c1 = &desc->comps[c];
|
|
|
|
struct mp_imgfmt_comp_desc *c2 = &desc->comps[i];
|
video: add pixel component location metadata
I thought I'd probably want something like this, so the hardcoded stuff
in repack.c can be removed eventually. Of course this has no purpose at
all, and will not have any. (For now, this provides only metadata, and
nothing uses it, apart from the "test" that dumps it as text.)
This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite,
because the format is 100% useless). Support for some mpv-only formats
is missing, ironically.
The code goes through _lengths_ to try to make sense out of the FFmpeg
AVPixFmtDescriptor data. Which is even more amazing that the new
metadata basically mirrors pixdesc, and just adds to it. Considering
code complexity and speed issues (it takes time to crunch through all
this shit all the time), and especially the fact that pixdesc is very
_incomplete_, it would probably better to have our own table to all
formats. But then we'd not scramble every time FFmpeg adds a new format,
which would be annoying. On the other hand, by using pixdesc, we get the
excitement to see whether this code will work, or break everything in
catastrophic ways.
The data structure still sucks a lot. Maybe I'll redo it again. The text
dump is weirdly differently formatted than the C struct - because I'm
not happy with the representation. Maybe I'll redo it all over again.
In summary: this commit does nothing.
2020-05-17 22:24:31 +00:00
|
|
|
if (c1->plane == c2->plane) {
|
|
|
|
if (c1->offset + c1->size > c2->offset &&
|
|
|
|
c2->offset + c2->size > c1->offset)
|
|
|
|
any_shared_bits = true;
|
|
|
|
if ((c1->offset + c1->size + 7) / 8u > c2->offset / 8u &&
|
|
|
|
(c2->offset + c2->size + 7) / 8u > c1->offset / 8u)
|
|
|
|
any_shared_bytes = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (any_shared_bits) {
|
|
|
|
for (int c = 0; c < pd->nb_components; c++)
|
2020-05-19 21:58:36 +00:00
|
|
|
desc->comps[c] = (struct mp_imgfmt_comp_desc){0};
|
video: add pixel component location metadata
I thought I'd probably want something like this, so the hardcoded stuff
in repack.c can be removed eventually. Of course this has no purpose at
all, and will not have any. (For now, this provides only metadata, and
nothing uses it, apart from the "test" that dumps it as text.)
This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite,
because the format is 100% useless). Support for some mpv-only formats
is missing, ironically.
The code goes through _lengths_ to try to make sense out of the FFmpeg
AVPixFmtDescriptor data. Which is even more amazing that the new
metadata basically mirrors pixdesc, and just adds to it. Considering
code complexity and speed issues (it takes time to crunch through all
this shit all the time), and especially the fact that pixdesc is very
_incomplete_, it would probably better to have our own table to all
formats. But then we'd not scramble every time FFmpeg adds a new format,
which would be annoying. On the other hand, by using pixdesc, we get the
excitement to see whether this code will work, or break everything in
catastrophic ways.
The data structure still sucks a lot. Maybe I'll redo it again. The text
dump is weirdly differently formatted than the C struct - because I'm
not happy with the representation. Maybe I'll redo it all over again.
In summary: this commit does nothing.
2020-05-17 22:24:31 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// Many important formats have padding within an access word. For example
|
|
|
|
// yuv420p10 has the upper 6 bit cleared to 0; P010 has the lower 6 bits
|
|
|
|
// cleared to 0. Pixdesc cannot represent that these bits are 0. There are
|
|
|
|
// other formats where padding is not guaranteed to be 0, but they are
|
|
|
|
// described in the same way.
|
|
|
|
// Apply a heuristic that is supposed to identify formats which use
|
|
|
|
// guaranteed 0 padding. This could fail, but nobody said this pixdesc crap
|
|
|
|
// is robust.
|
|
|
|
for (int c = 0; c < pd->nb_components; c++) {
|
2020-05-19 21:58:36 +00:00
|
|
|
struct mp_imgfmt_comp_desc *cd = &desc->comps[c];
|
video: add pixel component location metadata
I thought I'd probably want something like this, so the hardcoded stuff
in repack.c can be removed eventually. Of course this has no purpose at
all, and will not have any. (For now, this provides only metadata, and
nothing uses it, apart from the "test" that dumps it as text.)
This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite,
because the format is 100% useless). Support for some mpv-only formats
is missing, ironically.
The code goes through _lengths_ to try to make sense out of the FFmpeg
AVPixFmtDescriptor data. Which is even more amazing that the new
metadata basically mirrors pixdesc, and just adds to it. Considering
code complexity and speed issues (it takes time to crunch through all
this shit all the time), and especially the fact that pixdesc is very
_incomplete_, it would probably better to have our own table to all
formats. But then we'd not scramble every time FFmpeg adds a new format,
which would be annoying. On the other hand, by using pixdesc, we get the
excitement to see whether this code will work, or break everything in
catastrophic ways.
The data structure still sucks a lot. Maybe I'll redo it again. The text
dump is weirdly differently formatted than the C struct - because I'm
not happy with the representation. Maybe I'll redo it all over again.
In summary: this commit does nothing.
2020-05-17 22:24:31 +00:00
|
|
|
// Note: rgb444 would defeat our heuristic if we checked only per comp.
|
|
|
|
// also, exclude "bitstream" formats due to monow/monob
|
|
|
|
int fsize = MP_ALIGN_UP(cd->size, 8);
|
|
|
|
if (!any_shared_bytes && el_bits == 8 && fsize != cd->size &&
|
|
|
|
fsize - cd->size <= (1 << 3))
|
|
|
|
{
|
|
|
|
if (!(cd->offset % 8u)) {
|
|
|
|
cd->pad = -(fsize - cd->size);
|
|
|
|
cd->size = fsize;
|
|
|
|
} else if (!((cd->offset + cd->size) % 8u)) {
|
|
|
|
cd->pad = fsize - cd->size;
|
|
|
|
cd->size = fsize;
|
|
|
|
cd->offset = MP_ALIGN_DOWN(cd->offset, 8);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// The alpha component always has ID 4 (index 3) in our representation, so
|
|
|
|
// move the alpha component to there.
|
|
|
|
if (has_alpha && pd->nb_components < 4) {
|
2020-05-19 21:58:36 +00:00
|
|
|
desc->comps[3] = desc->comps[pd->nb_components - 1];
|
|
|
|
desc->comps[pd->nb_components - 1] = (struct mp_imgfmt_comp_desc){0};
|
|
|
|
}
|
|
|
|
|
|
|
|
if (is_packed_ss_yuv) {
|
|
|
|
desc->flags |= MP_IMGFLAG_PACKED_SS_YUV;
|
|
|
|
desc->bpp[0] /= 1 << pd->log2_chroma_w;
|
2020-05-20 16:25:14 +00:00
|
|
|
} else if (!any_shared_bits) {
|
2020-05-19 21:58:36 +00:00
|
|
|
desc->flags |= MP_IMGFLAG_HAS_COMPS;
|
video: add pixel component location metadata
I thought I'd probably want something like this, so the hardcoded stuff
in repack.c can be removed eventually. Of course this has no purpose at
all, and will not have any. (For now, this provides only metadata, and
nothing uses it, apart from the "test" that dumps it as text.)
This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite,
because the format is 100% useless). Support for some mpv-only formats
is missing, ironically.
The code goes through _lengths_ to try to make sense out of the FFmpeg
AVPixFmtDescriptor data. Which is even more amazing that the new
metadata basically mirrors pixdesc, and just adds to it. Considering
code complexity and speed issues (it takes time to crunch through all
this shit all the time), and especially the fact that pixdesc is very
_incomplete_, it would probably better to have our own table to all
formats. But then we'd not scramble every time FFmpeg adds a new format,
which would be annoying. On the other hand, by using pixdesc, we get the
excitement to see whether this code will work, or break everything in
catastrophic ways.
The data structure still sucks a lot. Maybe I'll redo it again. The text
dump is weirdly differently formatted than the C struct - because I'm
not happy with the representation. Maybe I'll redo it all over again.
In summary: this commit does nothing.
2020-05-17 22:24:31 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
fail:
|
2020-05-19 21:58:36 +00:00
|
|
|
for (int n = 0; n < 4; n++)
|
|
|
|
desc->comps[n] = (struct mp_imgfmt_comp_desc){0};
|
video: add pixel component location metadata
I thought I'd probably want something like this, so the hardcoded stuff
in repack.c can be removed eventually. Of course this has no purpose at
all, and will not have any. (For now, this provides only metadata, and
nothing uses it, apart from the "test" that dumps it as text.)
This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite,
because the format is 100% useless). Support for some mpv-only formats
is missing, ironically.
The code goes through _lengths_ to try to make sense out of the FFmpeg
AVPixFmtDescriptor data. Which is even more amazing that the new
metadata basically mirrors pixdesc, and just adds to it. Considering
code complexity and speed issues (it takes time to crunch through all
this shit all the time), and especially the fact that pixdesc is very
_incomplete_, it would probably better to have our own table to all
formats. But then we'd not scramble every time FFmpeg adds a new format,
which would be annoying. On the other hand, by using pixdesc, we get the
excitement to see whether this code will work, or break everything in
catastrophic ways.
The data structure still sucks a lot. Maybe I'll redo it again. The text
dump is weirdly differently formatted than the C struct - because I'm
not happy with the representation. Maybe I'll redo it all over again.
In summary: this commit does nothing.
2020-05-17 22:24:31 +00:00
|
|
|
// Average bit size fallback.
|
2020-05-20 16:25:14 +00:00
|
|
|
desc->num_planes = av_pix_fmt_count_planes(fmt);
|
|
|
|
for (int p = 0; p < desc->num_planes; p++) {
|
video: add pixel component location metadata
I thought I'd probably want something like this, so the hardcoded stuff
in repack.c can be removed eventually. Of course this has no purpose at
all, and will not have any. (For now, this provides only metadata, and
nothing uses it, apart from the "test" that dumps it as text.)
This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite,
because the format is 100% useless). Support for some mpv-only formats
is missing, ironically.
The code goes through _lengths_ to try to make sense out of the FFmpeg
AVPixFmtDescriptor data. Which is even more amazing that the new
metadata basically mirrors pixdesc, and just adds to it. Considering
code complexity and speed issues (it takes time to crunch through all
this shit all the time), and especially the fact that pixdesc is very
_incomplete_, it would probably better to have our own table to all
formats. But then we'd not scramble every time FFmpeg adds a new format,
which would be annoying. On the other hand, by using pixdesc, we get the
excitement to see whether this code will work, or break everything in
catastrophic ways.
The data structure still sucks a lot. Maybe I'll redo it again. The text
dump is weirdly differently formatted than the C struct - because I'm
not happy with the representation. Maybe I'll redo it all over again.
In summary: this commit does nothing.
2020-05-17 22:24:31 +00:00
|
|
|
int ls = av_image_get_linesize(fmt, 256, p);
|
2020-05-19 21:58:36 +00:00
|
|
|
desc->bpp[p] = ls > 0 ? ls * 8 / 256 : 0;
|
video: add pixel component location metadata
I thought I'd probably want something like this, so the hardcoded stuff
in repack.c can be removed eventually. Of course this has no purpose at
all, and will not have any. (For now, this provides only metadata, and
nothing uses it, apart from the "test" that dumps it as text.)
This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite,
because the format is 100% useless). Support for some mpv-only formats
is missing, ironically.
The code goes through _lengths_ to try to make sense out of the FFmpeg
AVPixFmtDescriptor data. Which is even more amazing that the new
metadata basically mirrors pixdesc, and just adds to it. Considering
code complexity and speed issues (it takes time to crunch through all
this shit all the time), and especially the fact that pixdesc is very
_incomplete_, it would probably better to have our own table to all
formats. But then we'd not scramble every time FFmpeg adds a new format,
which would be annoying. On the other hand, by using pixdesc, we get the
excitement to see whether this code will work, or break everything in
catastrophic ways.
The data structure still sucks a lot. Maybe I'll redo it again. The text
dump is weirdly differently formatted than the C struct - because I'm
not happy with the representation. Maybe I'll redo it all over again.
In summary: this commit does nothing.
2020-05-17 22:24:31 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-05-20 16:25:14 +00:00
|
|
|
static bool mp_imgfmt_get_desc_from_pixdesc(int mpfmt, struct mp_imgfmt_desc *out)
|
2012-12-31 00:58:25 +00:00
|
|
|
{
|
2013-11-29 16:39:57 +00:00
|
|
|
enum AVPixelFormat fmt = imgfmt2pixfmt(mpfmt);
|
|
|
|
const AVPixFmtDescriptor *pd = av_pix_fmt_desc_get(fmt);
|
video: add pixel component location metadata
I thought I'd probably want something like this, so the hardcoded stuff
in repack.c can be removed eventually. Of course this has no purpose at
all, and will not have any. (For now, this provides only metadata, and
nothing uses it, apart from the "test" that dumps it as text.)
This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite,
because the format is 100% useless). Support for some mpv-only formats
is missing, ironically.
The code goes through _lengths_ to try to make sense out of the FFmpeg
AVPixFmtDescriptor data. Which is even more amazing that the new
metadata basically mirrors pixdesc, and just adds to it. Considering
code complexity and speed issues (it takes time to crunch through all
this shit all the time), and especially the fact that pixdesc is very
_incomplete_, it would probably better to have our own table to all
formats. But then we'd not scramble every time FFmpeg adds a new format,
which would be annoying. On the other hand, by using pixdesc, we get the
excitement to see whether this code will work, or break everything in
catastrophic ways.
The data structure still sucks a lot. Maybe I'll redo it again. The text
dump is weirdly differently formatted than the C struct - because I'm
not happy with the representation. Maybe I'll redo it all over again.
In summary: this commit does nothing.
2020-05-17 22:24:31 +00:00
|
|
|
if (!pd || pd->nb_components > 4)
|
2020-05-20 16:25:14 +00:00
|
|
|
return false;
|
2013-11-05 20:59:26 +00:00
|
|
|
|
2012-12-31 00:58:25 +00:00
|
|
|
struct mp_imgfmt_desc desc = {
|
|
|
|
.id = mpfmt,
|
|
|
|
.chroma_xs = pd->log2_chroma_w,
|
|
|
|
.chroma_ys = pd->log2_chroma_h,
|
|
|
|
};
|
|
|
|
|
2020-05-20 16:25:14 +00:00
|
|
|
if (pd->flags & AV_PIX_FMT_FLAG_ALPHA)
|
|
|
|
desc.flags |= MP_IMGFLAG_ALPHA;
|
2012-12-31 00:58:25 +00:00
|
|
|
|
2020-05-20 16:25:14 +00:00
|
|
|
if (pd->flags & AV_PIX_FMT_FLAG_HWACCEL)
|
|
|
|
desc.flags |= MP_IMGFLAG_TYPE_HW;
|
|
|
|
|
|
|
|
// Pixdesc does not provide a flag for XYZ, so this is the best we can do.
|
|
|
|
if (strncmp(pd->name, "xyz", 3) == 0) {
|
|
|
|
desc.flags |= MP_IMGFLAG_COLOR_XYZ;
|
|
|
|
} else if (pd->flags & AV_PIX_FMT_FLAG_RGB) {
|
|
|
|
desc.flags |= MP_IMGFLAG_COLOR_RGB;
|
|
|
|
} else if (fmt == AV_PIX_FMT_MONOBLACK || fmt == AV_PIX_FMT_MONOWHITE) {
|
|
|
|
desc.flags |= MP_IMGFLAG_COLOR_RGB;
|
|
|
|
} else if (fmt == AV_PIX_FMT_PAL8) {
|
|
|
|
desc.flags |= MP_IMGFLAG_COLOR_RGB | MP_IMGFLAG_TYPE_PAL8;
|
2020-05-19 21:58:36 +00:00
|
|
|
}
|
|
|
|
|
2020-05-20 16:25:14 +00:00
|
|
|
if (pd->flags & AV_PIX_FMT_FLAG_FLOAT)
|
|
|
|
desc.flags |= MP_IMGFLAG_TYPE_FLOAT;
|
|
|
|
|
|
|
|
// Educated guess.
|
|
|
|
if (!(desc.flags & MP_IMGFLAG_COLOR_MASK) &&
|
|
|
|
!(desc.flags & MP_IMGFLAG_TYPE_HW))
|
|
|
|
desc.flags |= MP_IMGFLAG_COLOR_YUV;
|
|
|
|
|
2020-05-19 21:58:36 +00:00
|
|
|
desc.align_x = 1 << desc.chroma_xs;
|
|
|
|
desc.align_y = 1 << desc.chroma_ys;
|
|
|
|
|
|
|
|
fill_pixdesc_layout(&desc, fmt, pd);
|
|
|
|
|
2020-05-20 16:25:14 +00:00
|
|
|
if (desc.flags & (MP_IMGFLAG_HAS_COMPS | MP_IMGFLAG_PACKED_SS_YUV)) {
|
|
|
|
if (!(desc.flags & MP_IMGFLAG_TYPE_MASK))
|
|
|
|
desc.flags |= MP_IMGFLAG_TYPE_UINT;
|
|
|
|
}
|
|
|
|
|
2020-05-19 21:58:36 +00:00
|
|
|
if (desc.bpp[0] % 8u && (pd->flags & AV_PIX_FMT_FLAG_BITSTREAM))
|
|
|
|
desc.align_x = 8 / desc.bpp[0]; // expect power of 2
|
2012-12-31 00:58:25 +00:00
|
|
|
|
video: add pixel component location metadata
I thought I'd probably want something like this, so the hardcoded stuff
in repack.c can be removed eventually. Of course this has no purpose at
all, and will not have any. (For now, this provides only metadata, and
nothing uses it, apart from the "test" that dumps it as text.)
This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite,
because the format is 100% useless). Support for some mpv-only formats
is missing, ironically.
The code goes through _lengths_ to try to make sense out of the FFmpeg
AVPixFmtDescriptor data. Which is even more amazing that the new
metadata basically mirrors pixdesc, and just adds to it. Considering
code complexity and speed issues (it takes time to crunch through all
this shit all the time), and especially the fact that pixdesc is very
_incomplete_, it would probably better to have our own table to all
formats. But then we'd not scramble every time FFmpeg adds a new format,
which would be annoying. On the other hand, by using pixdesc, we get the
excitement to see whether this code will work, or break everything in
catastrophic ways.
The data structure still sucks a lot. Maybe I'll redo it again. The text
dump is weirdly differently formatted than the C struct - because I'm
not happy with the representation. Maybe I'll redo it all over again.
In summary: this commit does nothing.
2020-05-17 22:24:31 +00:00
|
|
|
// Very heuristical.
|
2020-05-19 21:58:36 +00:00
|
|
|
bool is_be = desc.endian_shift > 0;
|
|
|
|
bool need_endian = (desc.comps[0].size % 8u && desc.bpp[0] > 8) ||
|
|
|
|
desc.comps[0].size > 8;
|
video: add pixel component location metadata
I thought I'd probably want something like this, so the hardcoded stuff
in repack.c can be removed eventually. Of course this has no purpose at
all, and will not have any. (For now, this provides only metadata, and
nothing uses it, apart from the "test" that dumps it as text.)
This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite,
because the format is 100% useless). Support for some mpv-only formats
is missing, ironically.
The code goes through _lengths_ to try to make sense out of the FFmpeg
AVPixFmtDescriptor data. Which is even more amazing that the new
metadata basically mirrors pixdesc, and just adds to it. Considering
code complexity and speed issues (it takes time to crunch through all
this shit all the time), and especially the fact that pixdesc is very
_incomplete_, it would probably better to have our own table to all
formats. But then we'd not scramble every time FFmpeg adds a new format,
which would be annoying. On the other hand, by using pixdesc, we get the
excitement to see whether this code will work, or break everything in
catastrophic ways.
The data structure still sucks a lot. Maybe I'll redo it again. The text
dump is weirdly differently formatted than the C struct - because I'm
not happy with the representation. Maybe I'll redo it all over again.
In summary: this commit does nothing.
2020-05-17 22:24:31 +00:00
|
|
|
|
|
|
|
if (need_endian) {
|
|
|
|
desc.flags |= is_be ? MP_IMGFLAG_BE : MP_IMGFLAG_LE;
|
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
|
|
|
} else {
|
video: add pixel component location metadata
I thought I'd probably want something like this, so the hardcoded stuff
in repack.c can be removed eventually. Of course this has no purpose at
all, and will not have any. (For now, this provides only metadata, and
nothing uses it, apart from the "test" that dumps it as text.)
This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite,
because the format is 100% useless). Support for some mpv-only formats
is missing, ironically.
The code goes through _lengths_ to try to make sense out of the FFmpeg
AVPixFmtDescriptor data. Which is even more amazing that the new
metadata basically mirrors pixdesc, and just adds to it. Considering
code complexity and speed issues (it takes time to crunch through all
this shit all the time), and especially the fact that pixdesc is very
_incomplete_, it would probably better to have our own table to all
formats. But then we'd not scramble every time FFmpeg adds a new format,
which would be annoying. On the other hand, by using pixdesc, we get the
excitement to see whether this code will work, or break everything in
catastrophic ways.
The data structure still sucks a lot. Maybe I'll redo it again. The text
dump is weirdly differently formatted than the C struct - because I'm
not happy with the representation. Maybe I'll redo it all over again.
In summary: this commit does nothing.
2020-05-17 22:24:31 +00:00
|
|
|
desc.flags |= MP_IMGFLAG_LE | MP_IMGFLAG_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
|
|
|
|
2020-05-20 16:25:14 +00:00
|
|
|
*out = desc;
|
|
|
|
return true;
|
2020-05-19 21:58:36 +00:00
|
|
|
}
|
2012-12-31 00:58:25 +00:00
|
|
|
|
2020-05-19 21:58:36 +00:00
|
|
|
bool mp_imgfmt_get_packed_yuv_locations(int imgfmt, uint8_t *luma_offsets)
|
|
|
|
{
|
|
|
|
struct mp_imgfmt_desc desc = mp_imgfmt_get_desc(imgfmt);
|
|
|
|
if (!(desc.flags & MP_IMGFLAG_PACKED_SS_YUV))
|
|
|
|
return false;
|
2012-12-25 21:29:49 +00:00
|
|
|
|
2020-05-19 21:58:36 +00:00
|
|
|
assert(desc.num_planes == 1);
|
|
|
|
|
|
|
|
// Guess at which positions the additional luma samples are. We iterate
|
|
|
|
// starting with the first byte, and then put a luma sample at places
|
|
|
|
// not covered by other luma/chroma.
|
|
|
|
// Pixdesc does not and can not provide this information. This heuristic
|
|
|
|
// may fail in certain cases. What a load of bullshit, right?
|
|
|
|
int lsize = desc.comps[0].size;
|
|
|
|
int cur_offset = 0;
|
|
|
|
for (int lsample = 1; lsample < (1 << desc.chroma_xs); lsample++) {
|
|
|
|
while (1) {
|
|
|
|
if (cur_offset + lsize > desc.bpp[0] * desc.align_x)
|
|
|
|
return false;
|
|
|
|
bool free = true;
|
|
|
|
for (int c = 0; c < 3; c++) {
|
|
|
|
struct mp_imgfmt_comp_desc *cd = &desc.comps[c];
|
|
|
|
if (!cd->size)
|
|
|
|
continue;
|
|
|
|
if (cd->offset + cd->size > cur_offset &&
|
|
|
|
cur_offset + lsize > cd->offset)
|
|
|
|
{
|
|
|
|
free = false;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (free)
|
|
|
|
break;
|
|
|
|
cur_offset += lsize;
|
|
|
|
}
|
|
|
|
luma_offsets[lsample] = cur_offset;
|
|
|
|
cur_offset += lsize;
|
|
|
|
}
|
2012-12-25 21:29:49 +00:00
|
|
|
|
2020-05-19 21:58:36 +00:00
|
|
|
luma_offsets[0] = desc.comps[0].offset;
|
|
|
|
return true;
|
2012-12-31 00:58:25 +00:00
|
|
|
}
|
|
|
|
|
2020-05-20 16:25:14 +00:00
|
|
|
static bool get_native_desc(int mpfmt, struct mp_imgfmt_desc *desc)
|
|
|
|
{
|
|
|
|
const struct mp_imgfmt_entry *p = get_mp_desc(mpfmt);
|
|
|
|
if (!p || !p->desc.flags)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
*desc = p->desc;
|
|
|
|
|
|
|
|
// Fill in some fields mp_imgfmt_entry.desc is not required to set.
|
|
|
|
|
|
|
|
desc->id = mpfmt;
|
|
|
|
|
|
|
|
for (int n = 0; n < MP_NUM_COMPONENTS; n++) {
|
|
|
|
struct mp_imgfmt_comp_desc *cd = &desc->comps[n];
|
|
|
|
if (cd->size)
|
|
|
|
desc->num_planes = MPMAX(desc->num_planes, cd->plane + 1);
|
|
|
|
desc->bpp[cd->plane] =
|
|
|
|
MPMAX(desc->bpp[cd->plane], MP_ALIGN_UP(cd->offset + cd->size, 8));
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!desc->align_x && !desc->align_y) {
|
|
|
|
desc->align_x = 1 << desc->chroma_xs;
|
|
|
|
desc->align_y = 1 << desc->chroma_ys;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (desc->num_planes)
|
|
|
|
desc->flags |= MP_IMGFLAG_HAS_COMPS | MP_IMGFLAG_NE;
|
|
|
|
|
|
|
|
if (!(desc->flags & MP_IMGFLAG_TYPE_MASK))
|
|
|
|
desc->flags |= MP_IMGFLAG_TYPE_UINT;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2020-05-21 00:29:05 +00:00
|
|
|
int mp_imgfmt_desc_get_num_comps(struct mp_imgfmt_desc *desc)
|
2020-05-20 16:25:14 +00:00
|
|
|
{
|
2020-05-21 00:29:05 +00:00
|
|
|
int flags = desc->flags;
|
2020-05-20 16:25:14 +00:00
|
|
|
if (!(flags & MP_IMGFLAG_COLOR_MASK))
|
|
|
|
return 0;
|
|
|
|
return 3 + (flags & MP_IMGFLAG_GRAY ? -2 : 0) + !!(flags & MP_IMGFLAG_ALPHA);
|
|
|
|
}
|
|
|
|
|
|
|
|
struct mp_imgfmt_desc mp_imgfmt_get_desc(int mpfmt)
|
|
|
|
{
|
|
|
|
struct mp_imgfmt_desc desc;
|
|
|
|
|
|
|
|
if (!get_native_desc(mpfmt, &desc) &&
|
|
|
|
!mp_imgfmt_get_desc_from_pixdesc(mpfmt, &desc))
|
|
|
|
return (struct mp_imgfmt_desc){0};
|
|
|
|
|
|
|
|
for (int p = 0; p < desc.num_planes; p++) {
|
|
|
|
desc.xs[p] = (p == 1 || p == 2) ? desc.chroma_xs : 0;
|
|
|
|
desc.ys[p] = (p == 1 || p == 2) ? desc.chroma_ys : 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool is_ba = desc.num_planes > 0;
|
|
|
|
for (int p = 0; p < desc.num_planes; p++)
|
|
|
|
is_ba = !(desc.bpp[p] % 8u);
|
|
|
|
|
|
|
|
if (is_ba)
|
|
|
|
desc.flags |= MP_IMGFLAG_BYTE_ALIGNED;
|
|
|
|
|
|
|
|
if (desc.flags & MP_IMGFLAG_HAS_COMPS) {
|
|
|
|
if (desc.comps[3].size)
|
|
|
|
desc.flags |= MP_IMGFLAG_ALPHA;
|
|
|
|
|
|
|
|
// Assuming all colors are (CCC+[A]) or (C+[A]), the latter being gray.
|
|
|
|
if (!desc.comps[1].size)
|
|
|
|
desc.flags |= MP_IMGFLAG_GRAY;
|
|
|
|
|
|
|
|
bool bb = true;
|
|
|
|
for (int n = 0; n < MP_NUM_COMPONENTS; n++) {
|
|
|
|
if (desc.comps[n].offset % 8u || desc.comps[n].size % 8u)
|
|
|
|
bb = false;
|
|
|
|
}
|
|
|
|
if (bb)
|
|
|
|
desc.flags |= MP_IMGFLAG_BYTES;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ((desc.flags & (MP_IMGFLAG_YUV | MP_IMGFLAG_RGB))
|
|
|
|
&& (desc.flags & MP_IMGFLAG_HAS_COMPS)
|
|
|
|
&& (desc.flags & MP_IMGFLAG_BYTES)
|
|
|
|
&& ((desc.flags & MP_IMGFLAG_TYPE_MASK) == MP_IMGFLAG_TYPE_UINT))
|
|
|
|
{
|
2020-05-21 00:29:05 +00:00
|
|
|
int cnt = mp_imgfmt_desc_get_num_comps(&desc);
|
2020-05-20 16:25:14 +00:00
|
|
|
bool same_depth = true;
|
|
|
|
for (int p = 0; p < desc.num_planes; p++)
|
|
|
|
same_depth &= desc.bpp[p] == desc.bpp[0];
|
|
|
|
if (same_depth && cnt == desc.num_planes) {
|
|
|
|
if (desc.flags & MP_IMGFLAG_YUV) {
|
|
|
|
desc.flags |= MP_IMGFLAG_YUV_P;
|
|
|
|
} else {
|
|
|
|
desc.flags |= MP_IMGFLAG_RGB_P;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (cnt == 3 && desc.num_planes == 2 &&
|
|
|
|
desc.bpp[1] == desc.bpp[0] * 2 &&
|
|
|
|
(desc.flags & MP_IMGFLAG_YUV))
|
|
|
|
{
|
|
|
|
|
|
|
|
desc.flags |= MP_IMGFLAG_YUV_NV;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return desc;
|
|
|
|
}
|
|
|
|
|
2017-06-29 18:51:37 +00:00
|
|
|
static bool validate_regular_imgfmt(const struct mp_regular_imgfmt *fmt)
|
|
|
|
{
|
|
|
|
bool present[MP_NUM_COMPONENTS] = {0};
|
|
|
|
int n_comp = 0;
|
|
|
|
|
|
|
|
for (int n = 0; n < fmt->num_planes; n++) {
|
|
|
|
const struct mp_regular_imgfmt_plane *plane = &fmt->planes[n];
|
|
|
|
n_comp += plane->num_components;
|
|
|
|
if (n_comp > MP_NUM_COMPONENTS)
|
|
|
|
return false;
|
|
|
|
if (!plane->num_components)
|
|
|
|
return false; // no empty planes in between allowed
|
|
|
|
|
|
|
|
bool pad_only = true;
|
|
|
|
int chroma_luma = 0; // luma: 1, chroma: 2, both: 3
|
|
|
|
for (int i = 0; i < plane->num_components; i++) {
|
|
|
|
int comp = plane->components[i];
|
|
|
|
if (comp > MP_NUM_COMPONENTS)
|
|
|
|
return false;
|
|
|
|
if (comp == 0)
|
|
|
|
continue;
|
|
|
|
pad_only = false;
|
|
|
|
if (present[comp - 1])
|
|
|
|
return false; // no duplicates
|
|
|
|
present[comp - 1] = true;
|
|
|
|
chroma_luma |= (comp == 2 || comp == 3) ? 2 : 1;
|
|
|
|
}
|
|
|
|
if (pad_only)
|
|
|
|
return false; // no planes with only padding allowed
|
2020-04-21 21:11:23 +00:00
|
|
|
if ((fmt->chroma_xs > 0 || fmt->chroma_ys > 0) && chroma_luma == 3)
|
2017-06-29 18:51:37 +00:00
|
|
|
return false; // separate chroma/luma planes required
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!(present[0] || present[3]) || // at least component 1 or alpha needed
|
|
|
|
(present[1] && !present[0]) || // component 2 requires component 1
|
|
|
|
(present[2] && !present[1])) // component 3 requires component 2
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2020-05-20 16:25:14 +00:00
|
|
|
static enum mp_csp get_forced_csp_from_flags(int flags)
|
2017-06-29 18:51:37 +00:00
|
|
|
{
|
2020-05-20 16:25:14 +00:00
|
|
|
if (flags & MP_IMGFLAG_COLOR_XYZ)
|
2017-06-29 18:51:37 +00:00
|
|
|
return MP_CSP_XYZ;
|
|
|
|
|
2020-05-20 16:25:14 +00:00
|
|
|
if (flags & MP_IMGFLAG_COLOR_RGB)
|
2017-10-09 13:15:53 +00:00
|
|
|
return MP_CSP_RGB;
|
|
|
|
|
2017-06-29 18:51:37 +00:00
|
|
|
return MP_CSP_AUTO;
|
|
|
|
}
|
|
|
|
|
2020-05-20 16:25:14 +00:00
|
|
|
enum mp_csp mp_imgfmt_get_forced_csp(int imgfmt)
|
2017-08-15 15:00:35 +00:00
|
|
|
{
|
2020-05-20 16:25:14 +00:00
|
|
|
return get_forced_csp_from_flags(mp_imgfmt_get_desc(imgfmt).flags);
|
|
|
|
}
|
2017-08-15 15:00:35 +00:00
|
|
|
|
2020-05-20 16:25:14 +00:00
|
|
|
static enum mp_component_type get_component_type_from_flags(int flags)
|
|
|
|
{
|
|
|
|
if (flags & MP_IMGFLAG_TYPE_UINT)
|
|
|
|
return MP_COMPONENT_TYPE_UINT;
|
2017-08-15 15:00:35 +00:00
|
|
|
|
2020-05-20 16:25:14 +00:00
|
|
|
if (flags & MP_IMGFLAG_TYPE_FLOAT)
|
2017-08-15 15:00:35 +00:00
|
|
|
return MP_COMPONENT_TYPE_FLOAT;
|
|
|
|
|
2020-05-20 16:25:14 +00:00
|
|
|
return MP_COMPONENT_TYPE_UNKNOWN;
|
|
|
|
}
|
|
|
|
|
|
|
|
enum mp_component_type mp_imgfmt_get_component_type(int imgfmt)
|
|
|
|
{
|
|
|
|
return get_component_type_from_flags(mp_imgfmt_get_desc(imgfmt).flags);
|
2017-08-15 15:00:35 +00:00
|
|
|
}
|
|
|
|
|
zimg: add support for big endian input and output
One of the extremely annoying dumb things in ffmpeg is that most pixel
formats are available as little endian and big endian variants. (The
sane way would be having native endian formats only.) Usually, most of
the real codecs use native formats only, while non-native formats are
used by fringe raw codecs only. But the PNG encoders and decoders
unfortunately use big endian formats, and since PNG it such a popular
format, this causes problems for us. In particular, the current zimg
wrapper will refuse to work (and mpv will fall back to sws) when writing
non-8 bit PNGs.
So add non-native endian support to zimg. This is done in a fairly
"generic" way (which means lots of potential for bugs). If input is a
"regular" format (and just byte-swapped), the rest happens
automatically, which happens to cover all interesting formats.
Some things could be more efficient; for example, unpacking is done on
the data before it's passed to the unpacker. You could make endian
swapping part of the actual unpacking process, which might be slightly
faster. You could avoid copying twice in some cases (such as when
there's no actual repacker, or if alignment needs to be corrected). But
I don't really care. It's reasonably fast for the normal case.
Not entirely sure whether this is correct. Some (but not many) formats
are covered by the tests, some I tested manually. Some I can't even
test, because libswscale doesn't support them (like nv20*).
2020-04-12 20:14:55 +00:00
|
|
|
int mp_find_other_endian(int imgfmt)
|
|
|
|
{
|
|
|
|
return pixfmt2imgfmt(av_pix_fmt_swap_endianness(imgfmt2pixfmt(imgfmt)));
|
|
|
|
}
|
|
|
|
|
2017-06-29 18:51:37 +00:00
|
|
|
bool mp_get_regular_imgfmt(struct mp_regular_imgfmt *dst, int imgfmt)
|
|
|
|
{
|
video: add pixel component location metadata
I thought I'd probably want something like this, so the hardcoded stuff
in repack.c can be removed eventually. Of course this has no purpose at
all, and will not have any. (For now, this provides only metadata, and
nothing uses it, apart from the "test" that dumps it as text.)
This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite,
because the format is 100% useless). Support for some mpv-only formats
is missing, ironically.
The code goes through _lengths_ to try to make sense out of the FFmpeg
AVPixFmtDescriptor data. Which is even more amazing that the new
metadata basically mirrors pixdesc, and just adds to it. Considering
code complexity and speed issues (it takes time to crunch through all
this shit all the time), and especially the fact that pixdesc is very
_incomplete_, it would probably better to have our own table to all
formats. But then we'd not scramble every time FFmpeg adds a new format,
which would be annoying. On the other hand, by using pixdesc, we get the
excitement to see whether this code will work, or break everything in
catastrophic ways.
The data structure still sucks a lot. Maybe I'll redo it again. The text
dump is weirdly differently formatted than the C struct - because I'm
not happy with the representation. Maybe I'll redo it all over again.
In summary: this commit does nothing.
2020-05-17 22:24:31 +00:00
|
|
|
struct mp_regular_imgfmt res = {0};
|
2017-06-29 18:51:37 +00:00
|
|
|
|
video: add pixel component location metadata
I thought I'd probably want something like this, so the hardcoded stuff
in repack.c can be removed eventually. Of course this has no purpose at
all, and will not have any. (For now, this provides only metadata, and
nothing uses it, apart from the "test" that dumps it as text.)
This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite,
because the format is 100% useless). Support for some mpv-only formats
is missing, ironically.
The code goes through _lengths_ to try to make sense out of the FFmpeg
AVPixFmtDescriptor data. Which is even more amazing that the new
metadata basically mirrors pixdesc, and just adds to it. Considering
code complexity and speed issues (it takes time to crunch through all
this shit all the time), and especially the fact that pixdesc is very
_incomplete_, it would probably better to have our own table to all
formats. But then we'd not scramble every time FFmpeg adds a new format,
which would be annoying. On the other hand, by using pixdesc, we get the
excitement to see whether this code will work, or break everything in
catastrophic ways.
The data structure still sucks a lot. Maybe I'll redo it again. The text
dump is weirdly differently formatted than the C struct - because I'm
not happy with the representation. Maybe I'll redo it all over again.
In summary: this commit does nothing.
2020-05-17 22:24:31 +00:00
|
|
|
struct mp_imgfmt_desc desc = mp_imgfmt_get_desc(imgfmt);
|
|
|
|
if (!desc.num_planes)
|
2020-04-21 20:56:45 +00:00
|
|
|
return false;
|
video: add pixel component location metadata
I thought I'd probably want something like this, so the hardcoded stuff
in repack.c can be removed eventually. Of course this has no purpose at
all, and will not have any. (For now, this provides only metadata, and
nothing uses it, apart from the "test" that dumps it as text.)
This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite,
because the format is 100% useless). Support for some mpv-only formats
is missing, ironically.
The code goes through _lengths_ to try to make sense out of the FFmpeg
AVPixFmtDescriptor data. Which is even more amazing that the new
metadata basically mirrors pixdesc, and just adds to it. Considering
code complexity and speed issues (it takes time to crunch through all
this shit all the time), and especially the fact that pixdesc is very
_incomplete_, it would probably better to have our own table to all
formats. But then we'd not scramble every time FFmpeg adds a new format,
which would be annoying. On the other hand, by using pixdesc, we get the
excitement to see whether this code will work, or break everything in
catastrophic ways.
The data structure still sucks a lot. Maybe I'll redo it again. The text
dump is weirdly differently formatted than the C struct - because I'm
not happy with the representation. Maybe I'll redo it all over again.
In summary: this commit does nothing.
2020-05-17 22:24:31 +00:00
|
|
|
res.num_planes = desc.num_planes;
|
|
|
|
|
2020-05-19 21:58:36 +00:00
|
|
|
if (desc.endian_shift || !(desc.flags & MP_IMGFLAG_HAS_COMPS))
|
2017-06-29 18:51:37 +00:00
|
|
|
return false;
|
|
|
|
|
2020-05-20 16:25:14 +00:00
|
|
|
res.component_type = get_component_type_from_flags(desc.flags);
|
2017-08-15 15:00:35 +00:00
|
|
|
if (!res.component_type)
|
|
|
|
return false;
|
|
|
|
|
2020-05-19 21:58:36 +00:00
|
|
|
struct mp_imgfmt_comp_desc *comp0 = &desc.comps[0];
|
video: add pixel component location metadata
I thought I'd probably want something like this, so the hardcoded stuff
in repack.c can be removed eventually. Of course this has no purpose at
all, and will not have any. (For now, this provides only metadata, and
nothing uses it, apart from the "test" that dumps it as text.)
This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite,
because the format is 100% useless). Support for some mpv-only formats
is missing, ironically.
The code goes through _lengths_ to try to make sense out of the FFmpeg
AVPixFmtDescriptor data. Which is even more amazing that the new
metadata basically mirrors pixdesc, and just adds to it. Considering
code complexity and speed issues (it takes time to crunch through all
this shit all the time), and especially the fact that pixdesc is very
_incomplete_, it would probably better to have our own table to all
formats. But then we'd not scramble every time FFmpeg adds a new format,
which would be annoying. On the other hand, by using pixdesc, we get the
excitement to see whether this code will work, or break everything in
catastrophic ways.
The data structure still sucks a lot. Maybe I'll redo it again. The text
dump is weirdly differently formatted than the C struct - because I'm
not happy with the representation. Maybe I'll redo it all over again.
In summary: this commit does nothing.
2020-05-17 22:24:31 +00:00
|
|
|
if (comp0->size < 1 || comp0->size > 64 || (comp0->size % 8u))
|
2017-06-29 18:51:37 +00:00
|
|
|
return false;
|
|
|
|
|
video: add pixel component location metadata
I thought I'd probably want something like this, so the hardcoded stuff
in repack.c can be removed eventually. Of course this has no purpose at
all, and will not have any. (For now, this provides only metadata, and
nothing uses it, apart from the "test" that dumps it as text.)
This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite,
because the format is 100% useless). Support for some mpv-only formats
is missing, ironically.
The code goes through _lengths_ to try to make sense out of the FFmpeg
AVPixFmtDescriptor data. Which is even more amazing that the new
metadata basically mirrors pixdesc, and just adds to it. Considering
code complexity and speed issues (it takes time to crunch through all
this shit all the time), and especially the fact that pixdesc is very
_incomplete_, it would probably better to have our own table to all
formats. But then we'd not scramble every time FFmpeg adds a new format,
which would be annoying. On the other hand, by using pixdesc, we get the
excitement to see whether this code will work, or break everything in
catastrophic ways.
The data structure still sucks a lot. Maybe I'll redo it again. The text
dump is weirdly differently formatted than the C struct - because I'm
not happy with the representation. Maybe I'll redo it all over again.
In summary: this commit does nothing.
2020-05-17 22:24:31 +00:00
|
|
|
res.component_size = comp0->size / 8u;
|
|
|
|
res.component_pad = comp0->pad;
|
2017-06-29 18:51:37 +00:00
|
|
|
|
video: add pixel component location metadata
I thought I'd probably want something like this, so the hardcoded stuff
in repack.c can be removed eventually. Of course this has no purpose at
all, and will not have any. (For now, this provides only metadata, and
nothing uses it, apart from the "test" that dumps it as text.)
This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite,
because the format is 100% useless). Support for some mpv-only formats
is missing, ironically.
The code goes through _lengths_ to try to make sense out of the FFmpeg
AVPixFmtDescriptor data. Which is even more amazing that the new
metadata basically mirrors pixdesc, and just adds to it. Considering
code complexity and speed issues (it takes time to crunch through all
this shit all the time), and especially the fact that pixdesc is very
_incomplete_, it would probably better to have our own table to all
formats. But then we'd not scramble every time FFmpeg adds a new format,
which would be annoying. On the other hand, by using pixdesc, we get the
excitement to see whether this code will work, or break everything in
catastrophic ways.
The data structure still sucks a lot. Maybe I'll redo it again. The text
dump is weirdly differently formatted than the C struct - because I'm
not happy with the representation. Maybe I'll redo it all over again.
In summary: this commit does nothing.
2020-05-17 22:24:31 +00:00
|
|
|
for (int n = 0; n < res.num_planes; n++) {
|
2020-05-19 21:58:36 +00:00
|
|
|
if (desc.bpp[n] % comp0->size)
|
2017-06-29 18:51:37 +00:00
|
|
|
return false;
|
2020-05-19 21:58:36 +00:00
|
|
|
res.planes[n].num_components = desc.bpp[n] / comp0->size;
|
video: add pixel component location metadata
I thought I'd probably want something like this, so the hardcoded stuff
in repack.c can be removed eventually. Of course this has no purpose at
all, and will not have any. (For now, this provides only metadata, and
nothing uses it, apart from the "test" that dumps it as text.)
This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite,
because the format is 100% useless). Support for some mpv-only formats
is missing, ironically.
The code goes through _lengths_ to try to make sense out of the FFmpeg
AVPixFmtDescriptor data. Which is even more amazing that the new
metadata basically mirrors pixdesc, and just adds to it. Considering
code complexity and speed issues (it takes time to crunch through all
this shit all the time), and especially the fact that pixdesc is very
_incomplete_, it would probably better to have our own table to all
formats. But then we'd not scramble every time FFmpeg adds a new format,
which would be annoying. On the other hand, by using pixdesc, we get the
excitement to see whether this code will work, or break everything in
catastrophic ways.
The data structure still sucks a lot. Maybe I'll redo it again. The text
dump is weirdly differently formatted than the C struct - because I'm
not happy with the representation. Maybe I'll redo it all over again.
In summary: this commit does nothing.
2020-05-17 22:24:31 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
for (int n = 0; n < MP_NUM_COMPONENTS; n++) {
|
2020-05-19 21:58:36 +00:00
|
|
|
struct mp_imgfmt_comp_desc *comp = &desc.comps[n];
|
video: add pixel component location metadata
I thought I'd probably want something like this, so the hardcoded stuff
in repack.c can be removed eventually. Of course this has no purpose at
all, and will not have any. (For now, this provides only metadata, and
nothing uses it, apart from the "test" that dumps it as text.)
This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite,
because the format is 100% useless). Support for some mpv-only formats
is missing, ironically.
The code goes through _lengths_ to try to make sense out of the FFmpeg
AVPixFmtDescriptor data. Which is even more amazing that the new
metadata basically mirrors pixdesc, and just adds to it. Considering
code complexity and speed issues (it takes time to crunch through all
this shit all the time), and especially the fact that pixdesc is very
_incomplete_, it would probably better to have our own table to all
formats. But then we'd not scramble every time FFmpeg adds a new format,
which would be annoying. On the other hand, by using pixdesc, we get the
excitement to see whether this code will work, or break everything in
catastrophic ways.
The data structure still sucks a lot. Maybe I'll redo it again. The text
dump is weirdly differently formatted than the C struct - because I'm
not happy with the representation. Maybe I'll redo it all over again.
In summary: this commit does nothing.
2020-05-17 22:24:31 +00:00
|
|
|
if (!comp->size)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
struct mp_regular_imgfmt_plane *plane = &res.planes[comp->plane];
|
2017-06-29 18:51:37 +00:00
|
|
|
|
|
|
|
res.num_planes = MPMAX(res.num_planes, comp->plane + 1);
|
|
|
|
|
|
|
|
// We support uniform depth only.
|
video: add pixel component location metadata
I thought I'd probably want something like this, so the hardcoded stuff
in repack.c can be removed eventually. Of course this has no purpose at
all, and will not have any. (For now, this provides only metadata, and
nothing uses it, apart from the "test" that dumps it as text.)
This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite,
because the format is 100% useless). Support for some mpv-only formats
is missing, ironically.
The code goes through _lengths_ to try to make sense out of the FFmpeg
AVPixFmtDescriptor data. Which is even more amazing that the new
metadata basically mirrors pixdesc, and just adds to it. Considering
code complexity and speed issues (it takes time to crunch through all
this shit all the time), and especially the fact that pixdesc is very
_incomplete_, it would probably better to have our own table to all
formats. But then we'd not scramble every time FFmpeg adds a new format,
which would be annoying. On the other hand, by using pixdesc, we get the
excitement to see whether this code will work, or break everything in
catastrophic ways.
The data structure still sucks a lot. Maybe I'll redo it again. The text
dump is weirdly differently formatted than the C struct - because I'm
not happy with the representation. Maybe I'll redo it all over again.
In summary: this commit does nothing.
2020-05-17 22:24:31 +00:00
|
|
|
if (comp->size != comp0->size || comp->pad != comp0->pad)
|
2017-06-29 18:51:37 +00:00
|
|
|
return false;
|
|
|
|
|
video: add pixel component location metadata
I thought I'd probably want something like this, so the hardcoded stuff
in repack.c can be removed eventually. Of course this has no purpose at
all, and will not have any. (For now, this provides only metadata, and
nothing uses it, apart from the "test" that dumps it as text.)
This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite,
because the format is 100% useless). Support for some mpv-only formats
is missing, ironically.
The code goes through _lengths_ to try to make sense out of the FFmpeg
AVPixFmtDescriptor data. Which is even more amazing that the new
metadata basically mirrors pixdesc, and just adds to it. Considering
code complexity and speed issues (it takes time to crunch through all
this shit all the time), and especially the fact that pixdesc is very
_incomplete_, it would probably better to have our own table to all
formats. But then we'd not scramble every time FFmpeg adds a new format,
which would be annoying. On the other hand, by using pixdesc, we get the
excitement to see whether this code will work, or break everything in
catastrophic ways.
The data structure still sucks a lot. Maybe I'll redo it again. The text
dump is weirdly differently formatted than the C struct - because I'm
not happy with the representation. Maybe I'll redo it all over again.
In summary: this commit does nothing.
2020-05-17 22:24:31 +00:00
|
|
|
// Size-aligned only.
|
|
|
|
int pos = comp->offset / comp->size;
|
|
|
|
if (comp->offset != pos * comp->size || pos >= MP_NUM_COMPONENTS)
|
2017-06-29 18:51:37 +00:00
|
|
|
return false;
|
|
|
|
|
|
|
|
if (plane->components[pos])
|
|
|
|
return false;
|
|
|
|
plane->components[pos] = n + 1;
|
|
|
|
}
|
|
|
|
|
video: add pixel component location metadata
I thought I'd probably want something like this, so the hardcoded stuff
in repack.c can be removed eventually. Of course this has no purpose at
all, and will not have any. (For now, this provides only metadata, and
nothing uses it, apart from the "test" that dumps it as text.)
This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite,
because the format is 100% useless). Support for some mpv-only formats
is missing, ironically.
The code goes through _lengths_ to try to make sense out of the FFmpeg
AVPixFmtDescriptor data. Which is even more amazing that the new
metadata basically mirrors pixdesc, and just adds to it. Considering
code complexity and speed issues (it takes time to crunch through all
this shit all the time), and especially the fact that pixdesc is very
_incomplete_, it would probably better to have our own table to all
formats. But then we'd not scramble every time FFmpeg adds a new format,
which would be annoying. On the other hand, by using pixdesc, we get the
excitement to see whether this code will work, or break everything in
catastrophic ways.
The data structure still sucks a lot. Maybe I'll redo it again. The text
dump is weirdly differently formatted than the C struct - because I'm
not happy with the representation. Maybe I'll redo it all over again.
In summary: this commit does nothing.
2020-05-17 22:24:31 +00:00
|
|
|
res.chroma_xs = desc.chroma_xs;
|
|
|
|
res.chroma_ys = desc.chroma_ys;
|
2017-06-29 18:51:37 +00:00
|
|
|
|
2020-05-20 16:25:14 +00:00
|
|
|
res.forced_csp = get_forced_csp_from_flags(desc.flags);
|
2019-11-02 00:00:32 +00:00
|
|
|
|
2017-06-29 18:51:37 +00:00
|
|
|
if (!validate_regular_imgfmt(&res))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
*dst = res;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2019-11-02 00:02:54 +00:00
|
|
|
static bool regular_imgfmt_equals(struct mp_regular_imgfmt *a,
|
|
|
|
struct mp_regular_imgfmt *b)
|
|
|
|
{
|
|
|
|
if (a->component_type != b->component_type ||
|
|
|
|
a->component_size != b->component_size ||
|
|
|
|
a->num_planes != b->num_planes ||
|
|
|
|
a->component_pad != b->component_pad ||
|
|
|
|
a->forced_csp != b->forced_csp ||
|
2020-04-21 21:11:23 +00:00
|
|
|
a->chroma_xs != b->chroma_xs ||
|
|
|
|
a->chroma_ys != b->chroma_ys)
|
2019-11-02 00:02:54 +00:00
|
|
|
return false;
|
|
|
|
|
|
|
|
for (int n = 0; n < a->num_planes; n++) {
|
|
|
|
int num_comps = a->planes[n].num_components;
|
|
|
|
if (num_comps != b->planes[n].num_components)
|
|
|
|
return false;
|
|
|
|
for (int i = 0; i < num_comps; i++) {
|
|
|
|
if (a->planes[n].components[i] != b->planes[n].components[i])
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Find a format that matches this one exactly.
|
|
|
|
int mp_find_regular_imgfmt(struct mp_regular_imgfmt *src)
|
|
|
|
{
|
|
|
|
for (int n = IMGFMT_START + 1; n < IMGFMT_END; n++) {
|
|
|
|
struct mp_regular_imgfmt f;
|
|
|
|
if (mp_get_regular_imgfmt(&f, n) && regular_imgfmt_equals(src, &f))
|
|
|
|
return n;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
2017-06-29 18:51:37 +00:00
|
|
|
|
vf_scale: replace ancient fallback image format selection
If video output and VO don't support the same format, a conversion
filter needs to be insert. Since a VO can support multiple formats, and
the filter chain also can deal with multiple formats, you basically have
to pick from a huge matrix of possible conversions.
The old MPlayer code had a quite naive algorithm: it first checked
whether any conversion from the list of preferred conversions matched,
and if not, it was falling back on checking a hardcoded list of output
formats (more or less sorted by quality). This had some unintended side-
effects, like not using obvious "replacement" formats, selecting the
wrong colorspace, selecting a bit depth that is too high or too low, and
more.
Use avcodec_find_best_pix_fmt_of_list() provided by FFmpeg instead. This
function was made for this purpose, and should select the "best" format.
Libav provides a similar function, but with a different name - there is
a function with the same name in FFmpeg, but it has different semantics
(I'm not sure if Libav or FFmpeg fucked up here).
This also removes handling of VFCAP_CSP_SUPPORTED vs.
VFCAP_CSP_SUPPORTED_BY_HW, which has no meaning anymore, except possibly
for filter chains with multiple scale filters.
Fixes #1494.
2015-01-21 17:33:47 +00:00
|
|
|
// Compare the dst image formats, and return the one which can carry more data
|
|
|
|
// (e.g. higher depth, more color components, lower chroma subsampling, etc.),
|
|
|
|
// with respect to what is required to keep most of the src format.
|
|
|
|
// Returns the imgfmt, or 0 on error.
|
|
|
|
int mp_imgfmt_select_best(int dst1, int dst2, int src)
|
|
|
|
{
|
|
|
|
enum AVPixelFormat dst1pxf = imgfmt2pixfmt(dst1);
|
|
|
|
enum AVPixelFormat dst2pxf = imgfmt2pixfmt(dst2);
|
|
|
|
enum AVPixelFormat srcpxf = imgfmt2pixfmt(src);
|
|
|
|
enum AVPixelFormat dstlist[] = {dst1pxf, dst2pxf, AV_PIX_FMT_NONE};
|
2015-01-21 20:49:15 +00:00
|
|
|
return pixfmt2imgfmt(avcodec_find_best_pix_fmt_of_list(dstlist, srcpxf, 1, 0));
|
vf_scale: replace ancient fallback image format selection
If video output and VO don't support the same format, a conversion
filter needs to be insert. Since a VO can support multiple formats, and
the filter chain also can deal with multiple formats, you basically have
to pick from a huge matrix of possible conversions.
The old MPlayer code had a quite naive algorithm: it first checked
whether any conversion from the list of preferred conversions matched,
and if not, it was falling back on checking a hardcoded list of output
formats (more or less sorted by quality). This had some unintended side-
effects, like not using obvious "replacement" formats, selecting the
wrong colorspace, selecting a bit depth that is too high or too low, and
more.
Use avcodec_find_best_pix_fmt_of_list() provided by FFmpeg instead. This
function was made for this purpose, and should select the "best" format.
Libav provides a similar function, but with a different name - there is
a function with the same name in FFmpeg, but it has different semantics
(I'm not sure if Libav or FFmpeg fucked up here).
This also removes handling of VFCAP_CSP_SUPPORTED vs.
VFCAP_CSP_SUPPORTED_BY_HW, which has no meaning anymore, except possibly
for filter chains with multiple scale filters.
Fixes #1494.
2015-01-21 17:33:47 +00:00
|
|
|
}
|
|
|
|
|
2018-01-16 10:37:21 +00:00
|
|
|
// Same as mp_imgfmt_select_best(), but with a list of dst formats.
|
|
|
|
int mp_imgfmt_select_best_list(int *dst, int num_dst, int src)
|
|
|
|
{
|
|
|
|
int best = 0;
|
|
|
|
for (int n = 0; n < num_dst; n++)
|
|
|
|
best = best ? mp_imgfmt_select_best(best, dst[n], src) : dst[n];
|
|
|
|
return best;
|
|
|
|
}
|