fuchsia.images2

添加时间：12

结构体

RectU

在 fuchsia.images2/math.fidl 中定义

二维笛卡尔空间中轴对齐的矩形区域 空间，包含无符号的 location 和距离字段。

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

已移除：18 添加：12

字段类型说明默认
x uint32

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

 无默认设置
y uint32

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

 无默认设置
width uint32

沿 x 轴的距离。

该区域包含从 x 开始并沿 X 轴。

 无默认设置
height uint32

沿 y 轴的距离。

该区域包含从 y 开始并沿 Y 轴。

 无默认设置

精英

ColorSpace 柔性

类型：uint32

在 fuchsia.images2/image_format.fidl 中定义

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

此列表对于颜色空间标准的每个变体都有一个单独的条目。

因此，我们是否应添加对 RGB 变体 709 的支持， 那么我们会在此列表中添加该变体的单独条目。同理 对于 2020 或 2100 的 RGB 变体。对于 YcCbcCrc 变体的 YcCbcCrc 变体 2020 年。对于 2100 的 ICtCp 变体也是如此。

请参阅 ImageFormatIsSupportedColorSpaceForPixelFormat() 了解 可能支持 PixelFormat 和 ColorSpace 的组合。

通常，ColorSpace 不支持任何符合以下条件的 PixelFormat： 每个样本的位数与颜色空间的规范不兼容， PixelFormat，在 RGB 与 YUV 方面不匹配。

“限制范围”指的是 定义为 （以及色度的 simlar），但不应解读为 保证不会出现超出标称“有限范围”的值。 换句话说，“范围有限”并不一定意味着 值低于黑色或高于白色，或者值超出了“受限”限制色度范围 对于“全范围”，黑色为 0，白色是可能/允许的最大数值 值（对于色度也类似）。

名称值说明
0

颜色空间类型无效。
1

sRGB、伽马转换函数和全范围（根据规范）
2

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

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

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

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

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

2020 YCbCr（不是 RGB，不是 YcCbcCrc），10 或 12 位， PixelFormat，具有初选，范围有限（非全范围），传输 函数（“gamma”）等，所有规格均符合广色域 SDR
8

2100 YCbCr（不是 RGB，不是 ICtCp），10 或 12 位， PixelFormat、BT.2020 原色（与 REC2020 的广色域相同）， 有限范围（非全范围）、PQ（又名 SMPTE ST 2084）HDR 传输 函数（不是 HLG，而不是 REC2020 和 REC709 使用的 SDR“gamma”），宽 色域 HDR
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 位

与 VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM 兼容。U 平面可能位于 图片的 B 或 R 平面（V 平面也是如此）；顺序可能是 取决于 VkBufferCollectionPropertiesFUCHSIA.samplerYcbcrConversionComponents.
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) 中，这是 RGB565。
110

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

与任何 Vulkan 格式都不兼容。

在 sysmem(1) 中，这是 RGB332。
111

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

与任何 Vulkan 格式都不兼容。

在 sysmem(1) 中，这是 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).可以将这样的值指定为 pixel_format_modifier 字段中的 PixelFormatModifier 值，尽管 缺少已定义的相应 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。

设置后，此字段的值必须大于等于“每宽度的步长字节数” Pixel"乘以 size.width。如果相等，则在 每行像素的末尾。如果较大，差额就是 内边距位于每行像素的末尾，以字节为单位。

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

作为一个具体例子，这种情况并不罕见（但也并非总是必要） BGR24（每像素 3 个字节），在每个像素的末尾留出一些填充 行，以使每行像素都以 4 字节对齐的偏移量开始， 图片起始位置（左上方像素）。该内边距的大小是 不一定可被像素的大小（以字节为单位）整除（“步长字节” 所以我们使用此字段来表示内边距，而不是 与尝试将内边距合并为更大的“假” size.width.
display_rect fuchsia.math/RectU

帧内用于显示的矩形。这里指位置 尺寸（以像素为单位）， 显示“整张图片”界面显示效果

x + width 必须 <= size.width，并且 y + height 必须 小于等于 size.height。

对于视频解码器的输出，display_rect 之外的像素为 一律不显示（在测试程序之外），但必须保留 正确的解码器函数。display_rect总会跌落 位于从 (0, 0) 开始且大小为 valid_size 的矩形内， 已设置 valid_size。换句话说，display_rect 是一个子集（不是 valid_size 的适当子集），而 valid_size 是 size 的子集（不一定是适当的子集）。

下游纹理过滤操作应避免让任何像素 影响任何显示区域 像素，以免右侧或底部边缘渗漏 由解码过程定义，但不适用于 。

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

警告：fuchsia.sysmem.Images2 (V1) 不处理非零 x、y，因此 此处的任何非零 x、y (V2) 均会阻止转换为 V1。由于 非零 x、y 在实践中的稀有度，甚至是 在某些情况下，V2 可能仍然假定 x 和 y 均为 0， 实现和测试非零 x, y 处理的实用原因。通过 向下游渲染和/或显示发送非零 x、y 的症状 假设 0、0 不是崩溃， 因为假设 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 格式，这是像素宽高比（又称采样宽高比） 也称为 SAR）。

生产者应确保宽度值和高度值相对重要 根据需要减小比例（用 GCF 除以 9）。

消费者应将未设置的此字段解读为未知像素 宽高比。在某些情况下，默认 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