summaryrefslogtreecommitdiffstats
path: root/video/img_format.h
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2020-05-18 00:24:31 +0200
committerwm4 <wm4@nowhere>2020-05-18 01:54:59 +0200
commit27e5416c124884758bb206bb5948221a5f00f87d (patch)
tree3c5a8bae440f24a83171439738490a5153900918 /video/img_format.h
parentcaee8748da5c25b928f699bfa9f1ac4a5f3ae0ce (diff)
downloadmpv-27e5416c124884758bb206bb5948221a5f00f87d.tar.bz2
mpv-27e5416c124884758bb206bb5948221a5f00f87d.tar.xz
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.
Diffstat (limited to 'video/img_format.h')
-rw-r--r--video/img_format.h57
1 files changed, 57 insertions, 0 deletions
diff --git a/video/img_format.h b/video/img_format.h
index ea46dbec70..712937292e 100644
--- a/video/img_format.h
+++ b/video/img_format.h
@@ -141,6 +141,63 @@ struct mp_regular_imgfmt {
bool mp_get_regular_imgfmt(struct mp_regular_imgfmt *dst, int imgfmt);
int mp_find_regular_imgfmt(struct mp_regular_imgfmt *src);
+struct mp_imgfmt_comp_desc {
+ // Plane on which this component is.
+ uint8_t plane;
+ // Bit offset of first sample, from start of the pixel group (little endian).
+ uint8_t offset : 6;
+ // Number of bits used by each sample.
+ uint8_t size : 6;
+ // Internal padding. See mp_regular_imgfmt.component_pad.
+ int8_t pad : 4;
+};
+
+// Describes component layout of a specific image format.
+// Complements struct mp_imgfmt_desc, mp_imgfmt_get_component_type(), and
+// mp_imgfmt_get_forced_csp().
+// struct mp_regular_imgfmt provides a simpler description in some cases.
+struct mp_imgfmt_layout {
+ // Size of a pixel on each plane. If bits is not a multiple of 8, this is
+ // what FFmpeg calls a bitstream format.
+ // For planar sub-sampled formats, this describes a sub-sample. For
+ // example, with yuv420p, both luma and chroma planes use bits=8, extra_w=0.
+ // mp_imgfmt_desc.align_x gives the number of pixels needed to reach byte
+ // align.
+ // If extra_w>0, this is the size of extra_w+1 pixels (bundled together).
+ uint8_t bits[MP_MAX_PLANES];
+
+ // Description for each component. This is indexed by component_type-1,
+ // where component_type is as in mp_regular_imgfmt_plane.components[x] (so
+ // 1=R, 2=G, etc.). Components not present, or which have an unknown layout,
+ // use size=0.
+ struct mp_imgfmt_comp_desc comps[MP_NUM_COMPONENTS];
+
+ // If !=0, this gives the word size in bytes for endian swapping that needs
+ // to be performed for converting to native endian. This is performed before
+ // any other unpacking steps, and for all data covered by bits.
+ uint8_t endian_bytes : 4;
+
+ // Number of extra pixels in a pixel group. Packed, sub-sampled YUV formats
+ // use extra_w>0. There are no other types of formats that use this. Packed
+ // sub-sampled is defined as mixed non-sub-sampled (luma, alpha) and sub-
+ // sampled (chroma) components on the same plane. There are extra_w+1 luma
+ // samples in the pixel group, but only 1 chroma sample of each type.
+ // NB: mp_imgfmt_desc.align_x gives the number of pixels needed to get a
+ // "super pixel" with full chroma information, even for w=1 formats.
+ uint8_t extra_w : 4;
+
+ // For packed sub-sampled YUV: positions of further luma samples. Generally,
+ // you can access extra_luma_offsets[x] for (x >= 0 && x < extra_w). Luma
+ // sample 0 is described in comps[0]; luma sample N (N>1) uses all fields in
+ // comps[0], except offset=extra_luma_offsets[N-1].
+ // In theory, alpha also requires extra offsets, but we do not support any
+ // packed YUV formats with alpha and sub-sampled chroma.
+ uint8_t extra_luma_offsets[3];
+};
+
+// Return description for the given format, or desc={0} if unavailable.
+void mp_imgfmt_get_layout(int imgfmt, struct mp_imgfmt_layout *desc);
+
// If imgfmt is valid, and there exists a format that is exactly the same, but
// has inverse endianness, return this other format. Otherwise return 0.
int mp_find_other_endian(int imgfmt);