fuchsia.images2

添加数量：12

结构

RectU

在 fuchsia.images2/math.fidl 中定义

2D 笛卡尔空间中的一整套矩形轴对齐区域，包含无符号位置和距离字段。

此类型不指定单位。使用此类型的协议应指定矢量空间的特性，包括方向和单位。

已移除：18 添加：12

字段类型说明默认
x uint32

矩形的原点在 x 轴上的位置。

 无默认取景方式
y uint32

矩形的原点在 y 轴上的位置。

 无默认取景方式
width uint32

沿 x 轴的距离。

该区域包含从 x 开始并沿 x 轴递增的 x 值。

 无默认取景方式
height uint32

沿 y 轴的距离。

该区域包含从 y 开始并沿 y 轴递增的 y 值。

 无默认取景方式

枚举

ColorSpace 灵活

类型：uint32

在 fuchsia.images2/image_format.fidl 中定义

表示用于解释视频像素值的颜色空间。

此列表为颜色空间标准的每个变体提供了单独的条目。

因此，如果我们要添加对 RGB 变体 709 的支持，则会在此列表中为该变体添加单独的条目。同样，对于 2020 或 2100 的 RGB 变体。同样，对于 2020 的 YcCbcCrc 变体。对 2100 的 ICtCp 变体也是如此。

如需了解是否支持 PixelFormat 和 ColorSpace 的组合，请参阅 ImageFormatIsSupportedColorSpaceForPixelFormat()。

通常，ColorSpace 的每样本位数与颜色空间规范不兼容的任何 PixelFormat，以及 RGB 与 YUV 不匹配的任何 PixelFormat 均不支持 ColorSpace。

以下注释中的“有限范围”是指将黑白定义为（色度类似）的位置，但不应解读为保证不存在超出标称“有限范围”的值。换句话说，“有限范围”并不一定意味着不存在低于黑色或高于白色的任何值，也不存在“有限”色度范围之外的值。对于“全范围”，黑色为 0，白色为可能/允许的最大数值（与色度类似）。

名称值说明
0

不是有效的颜色空间类型。
1

sRGB、伽玛转换函数和全范围（符合规范）
2

601 NTSC（“525 行”）YCbCr 原色，有限范围
3

601 NTSC（“525 line”）YCbCr 原色，全范围
4

601 PAL（“625 行”）YCbCr 原色，有限范围
5

601 PAL（“625 行”）YCbCr 原色，全范围
6

709 YCbCr（非 RGB），范围受限
7

2020 YCbCr（非 RGB，不是 YcCbcCrc），10 位或 12 位（根据 PixelFormat），具有原色、有限范围（非全范围）、转换函数（“灰度系数”）等，且均符合规范，广色域 SDR
8

2100 YCbCr（非 RGB，不是 ICtCp）、10 或 12 位（符合 PixelFormat）、BT.2020 原色（与 REC2020 相同广色域）、有限范围（非全范围）、PQ（也称为 SMPTE ST 2084）、HDR2 使用 HDR 色域 HLG 和 HDR 色域 HLG（非 SMPTE ST 2084）
9

像素格式不表示颜色，或者位于无法由此枚举中的其他条目描述的应用专用颜色空间中。
4294967294

客户端会明确指明，客户端并不在意选择 / 使用哪个颜色空间。

PixelFormat（灵活）

类型：uint32

在 fuchsia.images2/image_format.fidl 中定义

表示视频像素的编码方式。

格式名称中通道的顺序反映了通道的实际布局。

其中每个值都是主观的（与 Vulkan 相比），其中应包含的颜色空间。

名称值说明
0
1

仅限 RGB，每个 R/G/B/A 样本 8 位

与 VK_FORMAT_R8G8B8A8_UNORM 兼容。
119

仅限 RGB，每个 R/G/B/X 样本 8 位

当被视为不透明时，与 VK_FORMAT_R8G8B8A8_UNORM 兼容。
101

32bpp BGRA，1 个平面。仅限 RGB，每个 B/G/R/A 样本 8 位。

与 VK_FORMAT_B8G8R8A8_UNORM 兼容。

在 sysmem(1) 中，其为 BGRA32。
120

32bpp BGRA，1 个平面。仅限 RGB，每个 B/G/R/X 样本 8 位。

当被视为不透明时，与 VK_FORMAT_B8G8R8A8_UNORM 兼容。
102

仅限 YUV，每个 Y 样本 8 位

与 VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM 兼容。
103

仅限 YUV，每个 Y 样本 8 位

与任何 Vulkan 格式都不兼容。
104

仅限 YUV，每个 Y 样本 8 位

与 VK_FORMAT_G8_B8R8_2PLANE_420_UNORM 兼容。
105

仅限 YUV，每个 Y 样本 8 位

与 VK_FORMAT_G8B8G8R8_422_UNORM 兼容。
106

该值已预留，当前未使用。
107

仅限 YUV，每个 Y 样本 8 位

与使用 B 和 R 调配的 VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM 兼容。
108

24bpp BGR，1 个平面。仅限 RGB，每个 B/G/R 样本 8 位

与 VK_FORMAT_B8G8R8_UNORM 兼容。

在 sysmem(1) 中，其为 BGR24。
109

16bpp RGB，1 个平面。5 位 R、6 位 G、5 位 B

与 VK_FORMAT_R5G6B5_UNORM_PACK16 兼容。

在 sysmem(1) 中，该 ID 为 RGB565。
110

8bpp RGB，1 个平面。3 位 R、3 位 G、2 位 B

与任何 Vulkan 格式都不兼容。

在 sysmem(1) 中，该 ID 为 RGB332。
111

8bpp RGB，1 个平面。2 位 R、2 位 G、2 位 B

与任何 Vulkan 格式都不兼容。

在 sysmem(1) 中，该 ID 为 RGB2220。
112

8bpp，仅亮度（红色、绿色和蓝色具有相同的值。）

与 VK_FORMAT_R8_UNORM 兼容。

大多数客户端更倾向于使用 R8。
113

8bpp，仅限红色（绿色和蓝色将被解释为 0）。

与 VK_FORMAT_R8_UNORM 兼容。
114

16bpp RG，1 个平面。8 位 R、8 位 G。

与 VK_FORMAT_R8G8_UNORM 兼容。
115

32bpp RGBA，1 个平面。2 位 A，10 位 R/G/B。

与 VK_FORMAT_A2R10G10B10_UNORM_PACK32 兼容。
116

32bpp BGRA，1 个平面。2 位 A，10 位 R/G/B。

与 VK_FORMAT_A2B10G10R10_UNORM_PACK32 兼容。
117

仅限 YUV，每个 Y 样本 16 位

这与 NV12 类似，但采用 16 位样本，每个样本的后 6 位设置为零和/或忽略。每个 16 位样本的字节序都是主机字节序（LE 系统上的 LE，BE 系统上的 BE）。CbCr 平面首先具有 16 位 Cb，然后是 16 位 Cr，交错 Cb Cr Cb Cr 以此类推。

与 VK_FORMAT_G10X6_B10X6R10X6_2PLANE_420_UNORM_3PACK16 兼容。
118

24bpp RGB，1 个平面。仅限 RGB，每个 R/G/B 样本 8 位

与 VK_FORMAT_R8G8B8_UNORM 兼容。
4294967294

客户端会明确指明，客户端并不在意选择 / 使用哪种像素格式。设置此值时，客户端不得设置 pixel_format_modifier。

PixelFormatModifier 灵活

类型：uint64

在 fuchsia.images2/format_modifier.fidl 中定义

高 8 位是供应商代码。低 56 位由供应商定义。

定义的 PixelFormatModifier 值是具体、完整且有效的值（INVALID 和 DO_NOT_CARE 除外，它们有自己的含义）。

一些其他有效或可能有效的 pixel_format_modifier 值未被定义为 PixelFormatModifier 值，这通常是因为该值实际上用不到（或者可能是新使用但尚未在 PixelFormatModifier 中定义的值）。尽管没有已定义的相应 PixelFormatModifier 值，但允许在 pixel_format_modifier 字段中将这样的值指定为 PixelFormatModifier 值。如果在测试代码之外使用此值，请考虑将其添加为 PixelFormatModifier 中的定义值。所有这些值都必须符合高 8 位供应商代码（请勿在相应供应商代码之外定义/使用值）。

单独定义的 FORMATMODIFIER* uint64 值是特定于供应商的位字段值，本身并不完整的有效值。这些 uint64 值可用于根据供应商专用位字段创建或解释 PixelFormatModifier 值。

当 pixel_format_modifier 设置为支持的值（DO_NOT_CARE、INVALID、LINEAR 除外）时，系统会修改 pixel_format 字段以其他方式指定的像素数据的排列方式，这通常是为了允许以下某种组合：平铺、压缩（通常是无损，通常用于减少内存带宽，而不是帧缓冲区大小缩减）、事务消除、脏跟踪，但通常不修改 pixel_format 的位深。在某些情况下，会涉及每个图像或每个图块的标题，或类似问题。pixel_format 字段通常仍然需要设置为与 pixel_format_modifier 结合使用的有效受支持值，并且该 pixel_format 值也可以影响 ImageFormat 的总体含义。也就是说，名称的“修饰符”部分比“override”更准确。

名称值说明
72057594037927934
72057594037927935
0
72057594037927937
72057594037927938
72057594037927939
72057594054705154
72057594054705155
576460752303423489
576460752303423490
576460752303427584
576460752303427585
576460752303427586
576460752303431697
576460752303423601
576460752303427697
576460752303431793
576460752303435889
7421932185906577409

表

ImageFormat

在 fuchsia.images2/image_format.fidl 中定义

描述图片的格式。

序数字段类型说明
pixel_format PixelFormat

描述像素的编码方式。
pixel_format_modifier PixelFormatModifier

特定于供应商的像素格式修饰符。请参阅 format_modifier.fidl。
color_space ColorSpace

表示用于解释像素值的颜色空间。
size fuchsia.math/SizeU

图片的大小（以像素为单位）。

另请参阅 bytes_per_row（以及 size），以了解每个像素的数据在缓冲区中的位置。

并非缓冲区中所有可寻址像素位置都必须填充有效的像素数据。如需了解可能更小的有效像素矩形，请参阅 valid_size。

图像的右侧和底部可能有一些不会显示的有效像素。请参阅display_rect。
bytes_per_row uint32

每行的字节数。对于多平面 YUV 格式，这是指 Y 平面中每行的字节数。

如果未设置此字段，则每行像素的末尾都不会有内边距。换言之，如果未设置，步长等于“每宽度像素的步幅字节数”乘以 size.width。

设置后，此字段的值必须大于等于“每宽度像素的步长字节数”与 size.width 的乘积。如果相等，则每行像素的末尾都没有内边距。如果大于 0，差值即为每行像素末尾的内边距大小（以字节为单位）。

这也称为“步长”“行到行的偏移量”“行到行的偏移量”及其他名称。

举一个具体的例子：BGR24（每像素 3 字节）在每行末尾有一些内边距，因此每行像素从到图片开头（左上角像素）的 4 字节对齐偏移量开始，这并不罕见（但也并非总是必需）。该内边距的大小不一定可被像素大小（以字节为单位）整除（“每宽度像素的步长字节数”），因此我们使用此字段指明内边距，而不是尝试将内边距合并为较大的“虚构”size.width。
display_rect fuchsia.math/RectU

帧中用于显示的矩形。这是在以界面显示方式显示“整张图片”时，应显示的像素矩形的位置和大小（以像素为单位）。

x + width 必须小于等于 size.width，y + height 必须小于等于 size.height。

对于视频解码器的输出，display_rect 之外的像素绝不会显示（在测试程序之外），但必须保留以确保解码器功能正确运行。设置 valid_size 后，display_rect 将始终位于从 (0, 0) 开始且大小为 valid_size 的矩形内。换句话说，display_rect 是 valid_size 的子集（不一定是适当的子集），而 valid_size 是 size 的子集（不一定是适当的子集）。

下游纹理过滤操作应避免让 display_rect 以外的任何像素影响任何显示像素的视觉外观，以免在由解码过程定义但并非用于显示的任意像素中右侧或底部边缘泄露。

未设置此字段时的行为视协议而定。在某些协议中，可以先回退到 valid_size，然后再回退到 size。在其他情况下，可以实现直接回退到 size。在其他情况下，必须设置此字段，否则渠道将关闭。

警告：fuchsia.sysmem.Images2 (V1) 不处理非零 x, y，因此此处的任何非零 x, y (V2) 都将阻止转换为 V1。在实践中，由于非零 x, y 的罕见性，即使已迁移到 V2 的组件也可能在某些情况下仍假定 x 和 y 均为 0，直到有实际理由来实现和测试非零 x, y 的处理。向下游渲染和/或显示通道（假定 0, 0）发送非零 x, y 的症状是不正确的显示，而不是崩溃，因为假设 x, y 为 0, 0 不会导致读出缓冲区边界。

添加日期：18
valid_size fuchsia.math/SizeU

帧的大小，以包含有效像素数据的像素数量（在视频解码方面）而非哪些像素用于显示。

如需将 valid_size 转换为可直接与 display_rect 比较的矩形，可以使用 (x: 0, y: 0, width: valid_size.width, height: valid_size.height) 创建一个矩形。

对于视频解码器，valid_size 可以包含 display_rect 之外的一些像素。多余像素不会显示，并且不一定包含任何实际图像数据。通常情况下，在这些区域中看起来像真实图像数据的任何内容都只是视频压缩的痕迹，并且存在宏块其余部分的存在，尽管这些帧不在显示区域内，但可供后续帧引用，而且实际上并不是来自来源的任何其他“实际”像素。此区域中的像素值由编解码器解码过程定义，并且必须保留下来才能确保解码器正确运行。通常， valid_size 内和 display_rect 外的像素最大为宏块的大小减 1。valid_size 对于测试视频解码器和某些转码场景非常有用。
pixel_aspect_ratio fuchsia.math/SizeU

按预期显示视频的单个像素的宽高比。

对于 YUV 格式，这是指亮度 (AKA Y) 样本的像素宽高比（即样本宽高比，也称为 SAR）。

生产者应在必要时减少比例（将两者均除以 GCF），确保宽度值和高度值相对质量。

消费者应将此字段取消设置为未知的像素宽高比。在某些情况下，1:1 的默认值可能很合适，但消费者可能会通过 OOB 方式确定实际像素宽高比。

常量

名称值类型说明
FORMAT_MODIFIER_ARM_BCH_BIT 2048 uint64
FORMAT_MODIFIER_ARM_SPARSE_BIT 64 uint64
FORMAT_MODIFIER_ARM_SPLIT_BLOCK_BIT 32 uint64
FORMAT_MODIFIER_ARM_TE_BIT 4096 uint64
FORMAT_MODIFIER_ARM_TILED_HEADER_BIT 8192 uint64
FORMAT_MODIFIER_ARM_YUV_BIT 16 uint64
FORMAT_MODIFIER_INTEL_CCS_BIT 16777216 uint64

该格式在图块数据后面有一个颜色控制表面
FORMAT_MODIFIER_VENDOR_ALLWINNER 648518346341351424 uint64
添加数量：19
FORMAT_MODIFIER_VENDOR_AMD 144115188075855872 uint64
添加数量：19
FORMAT_MODIFIER_VENDOR_AMLOGIC 720575940379279360 uint64
添加数量：19
FORMAT_MODIFIER_VENDOR_ARM 576460752303423488 uint64
添加数量：19
FORMAT_MODIFIER_VENDOR_BROADCOM 504403158265495552 uint64
添加数量：19
FORMAT_MODIFIER_VENDOR_GOOGLE 7421932185906577408 uint64
添加数量：19
FORMAT_MODIFIER_VENDOR_INTEL 72057594037927936 uint64
添加数量：19
FORMAT_MODIFIER_VENDOR_NVIDIA 216172782113783808 uint64
添加数量：19
FORMAT_MODIFIER_VENDOR_QCOM 360287970189639680 uint64
添加数量：19
FORMAT_MODIFIER_VENDOR_SAMSUNG 288230376151711744 uint64
添加数量：19
FORMAT_MODIFIER_VENDOR_VIVANTE 432345564227567616 uint64
添加数量：19