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>
|
|
|
|
|
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;
|
video: some concessions to big endian hosts
The recent changes to the image format metadata broke big endian, and
that was intentional. Some things are inherent to little endian (like
the idea to coalesce bit and byte offsets into a single bit offset), and
they don't be fixed. But some obvious things can be fixed, such as
marking LE vs. BE formats the right way around on BE hosts.
The metadata is formally still in LE, except that if the LE/BE flag
matches the host endian, the host endian can be used when accessing
packed formats with bit shifts, or when computing byte aligned component
byte offsets. The former may work because formats with LE/BE variants
use the same bit offsets after byte swapping, the latter may work
because little endian is the natural concept for addressing memory. But
it will "subtly" fail to do the right thing in some cases, and code
using this can't know, so have fun.
Many things are broken, but this makes e.g. vo_gpu mostly work.
My general opinion about BE computers is that you should get a better
computer, you can get one for free from any garbage dump.
2020-06-17 16:15:51 +00:00
|
|
|
bool is_ne = MP_SELECT_LE_BE(false, true) == is_be;
|
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
|
|
|
|
|
|
|
// 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
|
|
|
|
img_format: fight ffmpeg pixdesc some more
This change attempts to fix detection of how endian swapping is to be
performed. Details can be found in the code comments.
It should not change anything, other than fixing handling of the
X2RGB10BE ffmpeg pixel format. This format was detected incorrectly, and
the component location metadata was discarded due to an internal
consistency check. With this commit, it is handled correctly. At first I
thought the X2RGB10BE ffmpeg pixdesc metadata was wrong, but it appears
to be correct. The problem with this format is that it's the first
packed RGB format that requires bit shift to access, and where the
endian word size is larger than the (rounded up) component size, all
while pixdesc would "require" you to perform 3 memory accesses (instead
of 1), and the code tries to reverse this.
It appears that trying to use the pixdesc metadata is much, much more
work than just duplicating it in a saner form. To be fair, most problems
are with big endian, and the mpv internal format does not care much
about endian _hosts_.
2020-06-17 14:15:15 +00:00
|
|
|
// Determine if there are any byte overlaps => relevant for determining
|
|
|
|
// access unit for endian, since pixdesc does not expose this, and assumes
|
|
|
|
// a weird model where you do separate memory fetches for each component.
|
|
|
|
bool any_shared_bytes = !!(pd->flags & AV_PIX_FMT_FLAG_BITSTREAM);
|
|
|
|
for (int c = 0; c < pd->nb_components; c++) {
|
|
|
|
for (int i = 0; i < c; i++) {
|
|
|
|
const AVComponentDescriptor *d1 = &pd->comp[c];
|
|
|
|
const AVComponentDescriptor *d2 = &pd->comp[i];
|
|
|
|
if (d1->plane == d2->plane) {
|
|
|
|
if (d1->offset + (d1->depth + 7) / 8u > d2->offset &&
|
|
|
|
d2->offset + (d2->depth + 7) / 8u > d1->offset)
|
|
|
|
any_shared_bytes = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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
|
img_format: fight ffmpeg pixdesc some more
This change attempts to fix detection of how endian swapping is to be
performed. Details can be found in the code comments.
It should not change anything, other than fixing handling of the
X2RGB10BE ffmpeg pixel format. This format was detected incorrectly, and
the component location metadata was discarded due to an internal
consistency check. With this commit, it is handled correctly. At first I
thought the X2RGB10BE ffmpeg pixdesc metadata was wrong, but it appears
to be correct. The problem with this format is that it's the first
packed RGB format that requires bit shift to access, and where the
endian word size is larger than the (rounded up) component size, all
while pixdesc would "require" you to perform 3 memory accesses (instead
of 1), and the code tries to reverse this.
It appears that trying to use the pixdesc metadata is much, much more
work than just duplicating it in a saner form. To be fair, most problems
are with big endian, and the mpv internal format does not care much
about endian _hosts_.
2020-06-17 14:15:15 +00:00
|
|
|
int word = mp_round_next_power_of_2(MPMAX(d->depth + shift, 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
|
|
|
// 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.
|
img_format: fight ffmpeg pixdesc some more
This change attempts to fix detection of how endian swapping is to be
performed. Details can be found in the code comments.
It should not change anything, other than fixing handling of the
X2RGB10BE ffmpeg pixel format. This format was detected incorrectly, and
the component location metadata was discarded due to an internal
consistency check. With this commit, it is handled correctly. At first I
thought the X2RGB10BE ffmpeg pixdesc metadata was wrong, but it appears
to be correct. The problem with this format is that it's the first
packed RGB format that requires bit shift to access, and where the
endian word size is larger than the (rounded up) component size, all
while pixdesc would "require" you to perform 3 memory accesses (instead
of 1), and the code tries to reverse this.
It appears that trying to use the pixdesc metadata is much, much more
work than just duplicating it in a saner form. To be fair, most problems
are with big endian, and the mpv internal format does not care much
about endian _hosts_.
2020-06-17 14:15:15 +00:00
|
|
|
if (is_be && el_bits == 8 && word == 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
|
|
|
offset += 8;
|
img_format: fight ffmpeg pixdesc some more
This change attempts to fix detection of how endian swapping is to be
performed. Details can be found in the code comments.
It should not change anything, other than fixing handling of the
X2RGB10BE ffmpeg pixel format. This format was detected incorrectly, and
the component location metadata was discarded due to an internal
consistency check. With this commit, it is handled correctly. At first I
thought the X2RGB10BE ffmpeg pixdesc metadata was wrong, but it appears
to be correct. The problem with this format is that it's the first
packed RGB format that requires bit shift to access, and where the
endian word size is larger than the (rounded up) component size, all
while pixdesc would "require" you to perform 3 memory accesses (instead
of 1), and the code tries to reverse this.
It appears that trying to use the pixdesc metadata is much, much more
work than just duplicating it in a saner form. To be fair, most problems
are with big endian, and the mpv internal format does not care much
about endian _hosts_.
2020-06-17 14:15:15 +00:00
|
|
|
// Pixdesc's model sometimes requires accesses with varying word-sizes,
|
|
|
|
// as seen in bgr565 and other formats. Also, it makes you read some
|
|
|
|
// formats with multiple endian-dependent accesses, where accessing a
|
|
|
|
// larger unit would make more sense. (Consider X2RGB10BE, for which
|
|
|
|
// pixdesc wants you to perform 3 * 2 byte accesses, and swap each of
|
|
|
|
// the read 16 bit words. What you really want is to swap the entire 4
|
|
|
|
// byte thing, and then extract the components with bit shifts).
|
|
|
|
// This is complete bullshit, so we transform it into word swaps before
|
|
|
|
// further processing. Care needs to be taken to not change formats like
|
|
|
|
// P010 or YA16 (prefer component accesses for them; P010 isn't even
|
|
|
|
// representable, because endian_shift is for all planes).
|
|
|
|
// As a heuristic, assume that if any components share a byte, the whole
|
|
|
|
// pixel is read as a single memory access and endian swapped at once.
|
video: some concessions to big endian hosts
The recent changes to the image format metadata broke big endian, and
that was intentional. Some things are inherent to little endian (like
the idea to coalesce bit and byte offsets into a single bit offset), and
they don't be fixed. But some obvious things can be fixed, such as
marking LE vs. BE formats the right way around on BE hosts.
The metadata is formally still in LE, except that if the LE/BE flag
matches the host endian, the host endian can be used when accessing
packed formats with bit shifts, or when computing byte aligned component
byte offsets. The former may work because formats with LE/BE variants
use the same bit offsets after byte swapping, the latter may work
because little endian is the natural concept for addressing memory. But
it will "subtly" fail to do the right thing in some cases, and code
using this can't know, so have fun.
Many things are broken, but this makes e.g. vo_gpu mostly work.
My general opinion about BE computers is that you should get a better
computer, you can get one for free from any garbage dump.
2020-06-17 16:15:51 +00:00
|
|
|
int access_size = 8;
|
|
|
|
if (plane_bits > 8) {
|
img_format: fight ffmpeg pixdesc some more
This change attempts to fix detection of how endian swapping is to be
performed. Details can be found in the code comments.
It should not change anything, other than fixing handling of the
X2RGB10BE ffmpeg pixel format. This format was detected incorrectly, and
the component location metadata was discarded due to an internal
consistency check. With this commit, it is handled correctly. At first I
thought the X2RGB10BE ffmpeg pixdesc metadata was wrong, but it appears
to be correct. The problem with this format is that it's the first
packed RGB format that requires bit shift to access, and where the
endian word size is larger than the (rounded up) component size, all
while pixdesc would "require" you to perform 3 memory accesses (instead
of 1), and the code tries to reverse this.
It appears that trying to use the pixdesc metadata is much, much more
work than just duplicating it in a saner form. To be fair, most problems
are with big endian, and the mpv internal format does not care much
about endian _hosts_.
2020-06-17 14:15:15 +00:00
|
|
|
if (any_shared_bytes) {
|
video: some concessions to big endian hosts
The recent changes to the image format metadata broke big endian, and
that was intentional. Some things are inherent to little endian (like
the idea to coalesce bit and byte offsets into a single bit offset), and
they don't be fixed. But some obvious things can be fixed, such as
marking LE vs. BE formats the right way around on BE hosts.
The metadata is formally still in LE, except that if the LE/BE flag
matches the host endian, the host endian can be used when accessing
packed formats with bit shifts, or when computing byte aligned component
byte offsets. The former may work because formats with LE/BE variants
use the same bit offsets after byte swapping, the latter may work
because little endian is the natural concept for addressing memory. But
it will "subtly" fail to do the right thing in some cases, and code
using this can't know, so have fun.
Many things are broken, but this makes e.g. vo_gpu mostly work.
My general opinion about BE computers is that you should get a better
computer, you can get one for free from any garbage dump.
2020-06-17 16:15:51 +00:00
|
|
|
access_size = plane_bits;
|
|
|
|
if (is_be && word != access_size) {
|
img_format: fight ffmpeg pixdesc some more
This change attempts to fix detection of how endian swapping is to be
performed. Details can be found in the code comments.
It should not change anything, other than fixing handling of the
X2RGB10BE ffmpeg pixel format. This format was detected incorrectly, and
the component location metadata was discarded due to an internal
consistency check. With this commit, it is handled correctly. At first I
thought the X2RGB10BE ffmpeg pixdesc metadata was wrong, but it appears
to be correct. The problem with this format is that it's the first
packed RGB format that requires bit shift to access, and where the
endian word size is larger than the (rounded up) component size, all
while pixdesc would "require" you to perform 3 memory accesses (instead
of 1), and the code tries to reverse this.
It appears that trying to use the pixdesc metadata is much, much more
work than just duplicating it in a saner form. To be fair, most problems
are with big endian, and the mpv internal format does not care much
about endian _hosts_.
2020-06-17 14:15:15 +00:00
|
|
|
// Before: offset = 8*byte_offset (with word bits of data)
|
|
|
|
// After: offset = bit_offset into swapped endian_size word
|
video: some concessions to big endian hosts
The recent changes to the image format metadata broke big endian, and
that was intentional. Some things are inherent to little endian (like
the idea to coalesce bit and byte offsets into a single bit offset), and
they don't be fixed. But some obvious things can be fixed, such as
marking LE vs. BE formats the right way around on BE hosts.
The metadata is formally still in LE, except that if the LE/BE flag
matches the host endian, the host endian can be used when accessing
packed formats with bit shifts, or when computing byte aligned component
byte offsets. The former may work because formats with LE/BE variants
use the same bit offsets after byte swapping, the latter may work
because little endian is the natural concept for addressing memory. But
it will "subtly" fail to do the right thing in some cases, and code
using this can't know, so have fun.
Many things are broken, but this makes e.g. vo_gpu mostly work.
My general opinion about BE computers is that you should get a better
computer, you can get one for free from any garbage dump.
2020-06-17 16:15:51 +00:00
|
|
|
offset = access_size - word - offset;
|
img_format: fight ffmpeg pixdesc some more
This change attempts to fix detection of how endian swapping is to be
performed. Details can be found in the code comments.
It should not change anything, other than fixing handling of the
X2RGB10BE ffmpeg pixel format. This format was detected incorrectly, and
the component location metadata was discarded due to an internal
consistency check. With this commit, it is handled correctly. At first I
thought the X2RGB10BE ffmpeg pixdesc metadata was wrong, but it appears
to be correct. The problem with this format is that it's the first
packed RGB format that requires bit shift to access, and where the
endian word size is larger than the (rounded up) component size, all
while pixdesc would "require" you to perform 3 memory accesses (instead
of 1), and the code tries to reverse this.
It appears that trying to use the pixdesc metadata is much, much more
work than just duplicating it in a saner form. To be fair, most problems
are with big endian, and the mpv internal format does not care much
about endian _hosts_.
2020-06-17 14:15:15 +00:00
|
|
|
}
|
|
|
|
} else {
|
video: some concessions to big endian hosts
The recent changes to the image format metadata broke big endian, and
that was intentional. Some things are inherent to little endian (like
the idea to coalesce bit and byte offsets into a single bit offset), and
they don't be fixed. But some obvious things can be fixed, such as
marking LE vs. BE formats the right way around on BE hosts.
The metadata is formally still in LE, except that if the LE/BE flag
matches the host endian, the host endian can be used when accessing
packed formats with bit shifts, or when computing byte aligned component
byte offsets. The former may work because formats with LE/BE variants
use the same bit offsets after byte swapping, the latter may work
because little endian is the natural concept for addressing memory. But
it will "subtly" fail to do the right thing in some cases, and code
using this can't know, so have fun.
Many things are broken, but this makes e.g. vo_gpu mostly work.
My general opinion about BE computers is that you should get a better
computer, you can get one for free from any garbage dump.
2020-06-17 16:15:51 +00:00
|
|
|
access_size = word;
|
img_format: fight ffmpeg pixdesc some more
This change attempts to fix detection of how endian swapping is to be
performed. Details can be found in the code comments.
It should not change anything, other than fixing handling of the
X2RGB10BE ffmpeg pixel format. This format was detected incorrectly, and
the component location metadata was discarded due to an internal
consistency check. With this commit, it is handled correctly. At first I
thought the X2RGB10BE ffmpeg pixdesc metadata was wrong, but it appears
to be correct. The problem with this format is that it's the first
packed RGB format that requires bit shift to access, and where the
endian word size is larger than the (rounded up) component size, all
while pixdesc would "require" you to perform 3 memory accesses (instead
of 1), and the code tries to reverse this.
It appears that trying to use the pixdesc metadata is much, much more
work than just duplicating it in a saner form. To be fair, most problems
are with big endian, and the mpv internal format does not care much
about endian _hosts_.
2020-06-17 14:15:15 +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
|
|
|
}
|
video: some concessions to big endian hosts
The recent changes to the image format metadata broke big endian, and
that was intentional. Some things are inherent to little endian (like
the idea to coalesce bit and byte offsets into a single bit offset), and
they don't be fixed. But some obvious things can be fixed, such as
marking LE vs. BE formats the right way around on BE hosts.
The metadata is formally still in LE, except that if the LE/BE flag
matches the host endian, the host endian can be used when accessing
packed formats with bit shifts, or when computing byte aligned component
byte offsets. The former may work because formats with LE/BE variants
use the same bit offsets after byte swapping, the latter may work
because little endian is the natural concept for addressing memory. But
it will "subtly" fail to do the right thing in some cases, and code
using this can't know, so have fun.
Many things are broken, but this makes e.g. vo_gpu mostly work.
My general opinion about BE computers is that you should get a better
computer, you can get one for free from any garbage dump.
2020-06-17 16:15:51 +00:00
|
|
|
int endian_size = (access_size && !is_ne) ? access_size : 8;
|
img_format: fight ffmpeg pixdesc some more
This change attempts to fix detection of how endian swapping is to be
performed. Details can be found in the code comments.
It should not change anything, other than fixing handling of the
X2RGB10BE ffmpeg pixel format. This format was detected incorrectly, and
the component location metadata was discarded due to an internal
consistency check. With this commit, it is handled correctly. At first I
thought the X2RGB10BE ffmpeg pixdesc metadata was wrong, but it appears
to be correct. The problem with this format is that it's the first
packed RGB format that requires bit shift to access, and where the
endian word size is larger than the (rounded up) component size, all
while pixdesc would "require" you to perform 3 memory accesses (instead
of 1), and the code tries to reverse this.
It appears that trying to use the pixdesc metadata is much, much more
work than just duplicating it in a saner form. To be fair, most problems
are with big endian, and the mpv internal format does not care much
about endian _hosts_.
2020-06-17 14:15:15 +00:00
|
|
|
int endian_shift = mp_log2(endian_size) - 3;
|
|
|
|
if (!MP_IS_POWER_OF_2(endian_size) || endian_shift < 0 || endian_shift > 3)
|
|
|
|
goto fail;
|
|
|
|
if (desc->endian_shift && desc->endian_shift != endian_shift)
|
|
|
|
goto fail;
|
|
|
|
desc->endian_shift = endian_shift;
|
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;
|
|
|
|
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 (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.
|
video: some concessions to big endian hosts
The recent changes to the image format metadata broke big endian, and
that was intentional. Some things are inherent to little endian (like
the idea to coalesce bit and byte offsets into a single bit offset), and
they don't be fixed. But some obvious things can be fixed, such as
marking LE vs. BE formats the right way around on BE hosts.
The metadata is formally still in LE, except that if the LE/BE flag
matches the host endian, the host endian can be used when accessing
packed formats with bit shifts, or when computing byte aligned component
byte offsets. The former may work because formats with LE/BE variants
use the same bit offsets after byte swapping, the latter may work
because little endian is the natural concept for addressing memory. But
it will "subtly" fail to do the right thing in some cases, and code
using this can't know, so have fun.
Many things are broken, but this makes e.g. vo_gpu mostly work.
My general opinion about BE computers is that you should get a better
computer, you can get one for free from any garbage dump.
2020-06-17 16:15:51 +00:00
|
|
|
bool is_ne = !desc.endian_shift;
|
2020-05-19 21:58:36 +00:00
|
|
|
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) {
|
video: some concessions to big endian hosts
The recent changes to the image format metadata broke big endian, and
that was intentional. Some things are inherent to little endian (like
the idea to coalesce bit and byte offsets into a single bit offset), and
they don't be fixed. But some obvious things can be fixed, such as
marking LE vs. BE formats the right way around on BE hosts.
The metadata is formally still in LE, except that if the LE/BE flag
matches the host endian, the host endian can be used when accessing
packed formats with bit shifts, or when computing byte aligned component
byte offsets. The former may work because formats with LE/BE variants
use the same bit offsets after byte swapping, the latter may work
because little endian is the natural concept for addressing memory. But
it will "subtly" fail to do the right thing in some cases, and code
using this can't know, so have fun.
Many things are broken, but this makes e.g. vo_gpu mostly work.
My general opinion about BE computers is that you should get a better
computer, you can get one for free from any garbage dump.
2020-06-17 16:15:51 +00:00
|
|
|
bool is_le = MP_SELECT_LE_BE(is_ne, !is_ne);
|
|
|
|
desc.flags |= is_le ? 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
|
|
|
} 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;
|
|
|
|
}
|
|
|
|
|
2023-11-04 02:55:38 +00:00
|
|
|
static enum pl_color_system 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)
|
2023-11-04 02:55:38 +00:00
|
|
|
return PL_COLOR_SYSTEM_XYZ;
|
2017-06-29 18:51:37 +00:00
|
|
|
|
2020-05-20 16:25:14 +00:00
|
|
|
if (flags & MP_IMGFLAG_COLOR_RGB)
|
2023-11-04 02:55:38 +00:00
|
|
|
return PL_COLOR_SYSTEM_RGB;
|
2017-10-09 13:15:53 +00:00
|
|
|
|
2023-11-04 02:55:38 +00:00
|
|
|
return PL_COLOR_SYSTEM_UNKNOWN;
|
2017-06-29 18:51:37 +00:00
|
|
|
}
|
|
|
|
|
2023-11-04 02:55:38 +00:00
|
|
|
enum pl_color_system 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;
|
|
|
|
}
|