AV12 is an internally conceived format that is actually
the combination of NV12 and an alpha plane.
This format is to add to gstreamer's webM
transparency support for vp8 and vp9. To this end, two
I420 streams are independently decoded simultaneously for
the actual content and the alpha plane respectively
and these are then combined into A420.
Since most hardware decoders output NV12, this patch adds
NV12+A to make the same workflow possible.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1152>
While so far it worked, we are about to introduce a format that break this
assuming. We have a format which consist of NV12 with alpha, and this format
does not have a direct mapping of the component against their plane indexes.
Fix this by using gst_video_format_info_component() introduced in 1.18 for
this purpose.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1151>
These parameters are incorrectly regarded as mutable in G-IR making them
"incompatible" with languages that are explicit about mutability like
Rust. In order to clean up the code and expected API there, update the
signatures here, right at the source (instead of overriding them in
Gir.toml and hoping for the best).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1005>
This adds linear 32x32 NV12 based tiles. This format is notably used by
Allwinner VCU and exposed in V4L2 as being "SUNXI Tiled" format. In this
patch we generalize the plane info calculation so we can share this part
with the 4L4 variant.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/754>
When using gst_video_info_align() user had no easy way to retrieve the
padded size and height of each plane.
This can easily be implemented in fill_planes() as it's already called
in align() with the padded height.
Ideally we'd add a plane_size field to GstVideoInfo but the remaining
padding is too small so that would be an ABI break.
Fix#618
The "field-order" is related for all interlace_mode modes except the
"progressive" mode. So instead of or'ing each mode we can use the
already supported GST_VIDEO_INFO_IS_INTERLACED macro.
Packed 10 bits per each R, G and B channel with MSB 2bits alpha channel.
This format is mapped to Windows' DXGI_FORMAT_R10G10B10A2_UNORM format which is
required for 10bits HDR rendering.
Note that this RGB10A2_LE format is R - B channel swapped version of BGR10A2_LE
It's invalid to have a 'interlace-mode=alternate' without the Interlaced caps
feature as well.
Modify gst_video_info_from_caps() to reject such case so we can easily
spot them in bugged elements.
Add a new macro that gives you the height of a field. It returns the
height of the full frame unless split-field (alternate) interlacing is
in use. Also GST_VIDEO_INFO_COMP_HEIGHT macro now uses this new macro to
get the height for its calculation.
https://bugzilla.gnome.org/show_bug.cgi?id=796106
Add a helper to set the interlacing mode while creating the GstVideoInfo
in addition to format and resolution. Using this helper will ensure that
size is correctly calculated for split-field interlacing mode.
https://bugzilla.gnome.org/show_bug.cgi?id=796106
Add a new interlace mode enum to represent buffers containing a single
field of an interlaced video in a buffer. The name is based on the
equivalent video format in the V4L2 API, V4L2_FIELD_ALTERNATE:
https://01.org/linuxgraphics/gfx-docs/drm/media/uapi/v4l/field-order.html
Since caps fields are optional, we also introduce a new caps feature,
"format:Interlaced" that always goes with "alternate" interlace mode to ensure
that caps for this incompatible format are incompatible with other interlaced
and progressive video caps.
https://bugzilla.gnome.org/show_bug.cgi?id=796106
This pixel format is a fully packed variant of NV12_10LE32,
a luma pixel would take 10bits in memory, without any
filled bits between pixels in a stride. The color range
follows the BT.2020 standard.
In order to get a better performance in hardware memory
operation, it may expend the stride, append zero data at the
end of echo lines.
Pack function by Nicolas Dufresne.
https://bugzilla.gnome.org/show_bug.cgi?id=795462
Signed-off-by: Nicolas Dufresne <nicolas@ndufresne.ca>
Signed-off-by: ayaka <ayaka@soulik.info>
This pixel format is a fully packed variant of NV12, a luma
pixel would take 10bits in memory, without any filled bits
between pixels in a stride. The color range follows
the BT.2020 standard.
In order to get a performance in hardware memory
operation, it may expend the stride, append zero data at the
end of echo lines.
Signed-off-by: ayaka <ayaka@soulik.info>
https://bugzilla.gnome.org/show_bug.cgi?id=795462
This adds a 10 bit variant for NV16 packed into 32 bits little endian
words. The MSB 2 bits are padding. This format is used on Xilinx SoC and
identified with the FOURCC XV20.
https://bugzilla.gnome.org/show_bug.cgi?id=789876
This add a 10bit variant of gray scale packed into 32bits little endian
words. The MSB 2 bits are padding and should be ignored. This format is
used on Xilinx SoC and is identified with the FOURCC XV10.
https://bugzilla.gnome.org/show_bug.cgi?id=789876
This adds a 10bit variant for NV12 which packs 3 10bit components
into little endian 32bit words. The MSB 2 bits are padding and should be
ignored. This format is used on Xilinx SoC and is identified with there
with the FOURCC XV15
https://bugzilla.gnome.org/show_bug.cgi?id=789876
The flags and field order weren't properly initialized in the
gst_video_info_init().
Furthermore in gst_video_info_from_caps() we might set unitiliazed
values previously, this only sets them if valid.
Usually this information is static for the whole stream, and various
container formats store this information inside the headers for the
whole stream.
Having it inside the caps for these cases simplifies code and makes it
possible to express these requirements more explicitly with the caps.
https://bugzilla.gnome.org/show_bug.cgi?id=771376
P010 is a YUV420 format with an interleaved U-V plane and 2-bytes per
component with the the color value stored in the 10 most significant
bits.
https://bugzilla.gnome.org/show_bug.cgi?id=761607
---
Changes since v2:
- Set bits=16 in DPTH10_10_10_HI
Changes since v1:
- Fixed x-offset calculation in uv.
- Added 6-bit shifts to FormatInfo.
