GIGE 协议摘录 —— GVSP 协议（三）（上）：https://developer.aliyun.com/article/1598399
8、JPEG 2000有效载荷类型（JPEG 2000 Payload Type）
本节描述了 ITU-T Rec T.800 的 GVSP 有效负载类型。更著名的名称是 JPEG 2000 。这种 JPEG 2000 有效载荷类型的灵感来自于 RFC5371 。
8.1 JPEG 2000原则（JPEG 2000 Principles）
一个 JPEG 2000 编码器用于编码（压缩）一个 “原始” 图像，以产生一个符合 JPEG 2000 标准的代码流。此代码流的格式由 JPEG 2000 标准定义。
下图显示了一个 JPEG 2000 代码流。JPEG 2000 代码流从主报头开始构造，从代码流的开始（SOC）标记、一个或多个贴图和代码流的结束（EOC）标记开始，以表示代码流的结束。每个平铺由一个从开始瓷砖部分头（SOT）标记开始到开始数据（SOD）标记和位流（一系列 JPEG 2000 数据包）组成。
需要注意的是，平铺被定义为一个分别进行转换和编码的图像的矩形区域。另外，我们也不应该将上面段落中引用的 JPEG 2000 数据包与用于通过以太网传输 JPEG 2000 码流的 IP 数据包相混淆。
8.2 针对 GVSP 的 JPEG 2000 实现（JPEG 2000 Implementation for GVSP）
JPEG 2000 代码流包括解码和显示压缩图像所需的大部分信息。本规范定义了一种 GVSP 有效负载格式，使 GVSP 接收器能够在不知道视频编码器的特性的情况下解码和显示所编码的图像。换句话说，JPEG 2000 GVSP 有效载荷视频源包括解码和显示编码图像所需的所有信息。它不依赖于使用能力公告和提供/应答协议。在 GigE 视觉系统中，假设一个更高层次的管理实体负责配置系统，以便视频接收器能够解码相关视频源提供的视频。因此，缺乏对能力公告和提供/回答协议的支持并不被认为是一个问题，因为当前用于未压缩视频传输的 GigE 视觉系统级模型并不依赖于这种机制。然而，如果人们认为需要，本规范并不阻止人们使用这样的协议。
包含一个压缩图像的数据的 JPEG 2000 编码流被作为一个 GVSP 数据块传输。
JPEG 2000 有效负载类型只支持 GigE 视觉扩展 ID 模式（即 GVSP 数据包的 EI 字段必须设置为 1 ）。
8.3 JPEG 2000 Data Leader Packet
数据引导包包括在 JPEG 2000 码流中不可获得的信息。
8.4 JPEG 2000 Data Payload Packet
8.5 JPEG 2000 Data Trailer Packet
8.6 JPEG 2000 All-in Packet
9、H.264有效载荷类型（H.264 Payload Type）
本节描述了 ITU-T Rec H.264 的 GVSP 有效负载类型，也称为 MPEG-4 Part 10 / MPEG-4 AVC 。这种 H.264 有效载荷类型的灵感来自于 RFC3984 。
9.1 H.264原则（H.264 Principles）
H.264 规范定义了两个概念层：视频编码层（VCL）和网络抽象层（NAL）。
VCL 包含编解码器的信号处理功能。它定义了诸如变换、量化、运动补偿预测和循环滤波器等机制。它遵循大多数帧间视频编解码器的一般概念，即基于宏块的编码器，它使用图像间预测与运动补偿和剩余信号的转换编码。宏块是一个 16x16 的 luma 样本块和两个相应的色度样本块，或一个单色图像的样本块，或使用三个独立的颜色平面编码的图片。VCL 编码器输出切片：一个比特流，其中包含整数个宏块的宏块数据和片头的信息（包含切片中第一个宏块的空间地址、初始量化参数和类似信息）。切片中的宏块通常按扫描顺序排列，除非使用灵活的宏块排序（FMO）语法指定了不同的宏块分配。图内预测仅在一个切片中使用。
网络抽象层（NAL）编码器将 VCL 编码器的片输出封装到网络抽象层单元（NAL 单元）中，这些单元适用于在包网络上传输或在面向包的多路复用环境中使用。
9.2 针对 GVSP 的 H.264 实现（H.264 Implementation for GVSP）
此规范定义了数据块传输一个访问单元。这使得可以在一个块中传输多个 NAL 单元，以优化传输开销。GVSP 数据有效负载包可以携带单个 NAL 单元、多个 NAL 单元或一个 NAL 单元的片段。这样做是为了通过优化用于传输访问单元的 GVSP 数据有效载荷数据包的数量来最小化 GVSP 传输开销。该方案的分支是，并不是所有的 GVSP 数据有效负载包都可以携带相同量的数据。这与大多数其他有效负载类型不同，其中只有最后一个数据有效负载包可能更小。因此，一个 H.264 接收器必须能够容纳一个 NAL 单元后的间隙。这个间隙一直延伸到下一个数据包的开始阶段。接收方使用由 SCPSx 寄存器提供的默认数据包大小，知道在 NAL 单元结束后的下一个数据包的位置。它解析 NAL 数据并跳过这些间隙。
本规范定义了一种让接收机解码和显示 H.264 编码的 GVSP 流的方法，而不需要了解编码器的功能。它不依赖于能力公告和提供/回答模型的实现。在 H.264 访问单元中不可用的信息被包含在 GVSP 数据块中。这可能会导致一些以太网带宽的浪费，因为额外的信息将在每个块中传递，而不是在流媒体会话启动之前进行自动协商。
H.264 有效负载类型仅支持 GigE 视觉扩展 ID 模式（即，GVSP 数据包的 EI 字段必须设置为 1 ）。
9.3 H.264 Data Leader Packet
数据先导包包括在 H.264 接入单元中不可用的信息。应该注意的是，时间戳不包括在内，因为它将包含在数据有效负载包中。
9.4 H.264 Data Payload Packet
下图显示了根据 RFC3984 中提供的封装方法的 H.264 数据有效载荷包的数据字段的布局。有关更多详情，请参考本 RFC 和 H.264 标准。
9.5 H.264 Data Trailer Packet
9.6 H.264 All-in Packet
10、多区域图像有效载荷类型（Multi-zone Image Payload Type）
如前所述，自本规范第 1.0 版以来可用的图像有效负载类型处理图像数据的光栅扫描传输。这是一个理想的适合相机，其中传感器输出数据在一个单一的点击。否则，照相机必须在传输前首先以光栅扫描格式重建图像。这可能会引入一些额外的延迟，并产生传输带宽的峰值。为了解决这种情况，GigEVision2.0 版本引入了可选的多区域图像有效载荷类型。
多区域图像有效载荷类型的目的是通过将图像划分为水平波段来改善来自多个点击传感器的图像数据传输的延迟特性。每一个水平带都被称为 “区域” 。一旦一个区域的下一个数据包准备好了，发射机就可以开始从某一个区域传输数据。
多区域图像对于支持传感器特别有用，它具有一些自上而下读取和一些自下而上读取的功能。
10.1 多区域图像原理（Multi-zone Image Principles）
多区域图像有效载荷类型的主要目标是改善多点击传感器从图像内的不同垂直位置开始的支持。例如，一个 2 次点击的传感器可以从图像的顶部开始有一个点击， 从底部开始有一个第二次点击。通过将图像划分为水平区域（见下面的图 25-43 ），相机能够更早地开始从这些区域的数据传输，减少总体延迟和内部图像缓冲。
11、设备特定有效载荷类型（Device-specific Payload Type）
此有效载荷类型可用于传输特定于设备（自定义）的信息。
11.1 Device-specific Data Leader Packet
11.2 Device-specific Data Payload Packet
11.3 Device-specific Data Trailer Packet
11.4 Device-specific All-in Packet
像素布局（Pixel Layouts）
本节描述了 GigE Vision 所支持的各种像素和图像布局。在 GigE 视觉 2.0 版本中，这些布局是基于 GenICam 像素格式命名约定的。
注意：本节中的图形使用小端模式，即 位0 在右边。这与像素格式命名约定相一致。因此，msb（位 7）在每个字节的左侧，而 lsb（位 0）在右边。
选择像素深度和格式的机制在 XML 设备描述文件中提供。
1、像素对齐（Pixel Alignment）
为了最小化GVSP接收端的像素处理时间，在有效载荷数据包中使用多字节的像素数据在默认情况下必须是小端化的。
GVSP 发射机可以实现一个转换器，将像素从小端转换为大端。当受支持时，可以使用 SCPSx 引导寄存器（pixel_endianess 字段）激活此转换器。SCCx 寄存器的 big_and_little_endian_supported 字段表示是否支持此转换器。
在下面的图中，字节 0 首先在数据线上发送，然后是字节 1 ，以此类推。
2、线和图像边界（Line and Image Boundaries）
GigE 视觉使用在像素格式命名约定中定义的图像填充。图像填充要求在直线的末尾不插入人工填充。
因此，对于某些分组和打包的像素格式，来自不同行的像素可能被组合在相同的字节中。例如，想象一个奇宽的图像（例如：宽度= 641像素）。如果像素成对组合（由于填充），那么第一行的最后一个像素将与第二行的第一个像素组合，如下所示。
另一个例子是当使用 Mono1p 时，图像宽度不是 8 像素的倍数。使用这种像素格式填充一个字节需要 8 个像素，因此一行的最后一个像素可能不会与字节边界对齐。
3、像素格式（Pixel Formats）
本节说明了GVSP本地支持的各种像素格式。这些像素格式基于像素格式命名约定文档，其中每个像素格式由5个特征定义：
- 组件和位置（Components and Location）
- #位（# bits）
- 标志指示灯（可选）（Sign indicator）
- 包装方式（可选）（Packing Style）
- 特定于接口的（可选的）（Interface-specific）
上述像素在一个名为 “GigE Vision appendix – Pixel Format” 的单独文档中详细说明。请参考本文档，特别是对于表 26-1 中列出的不符合 PFNC 要求的像素格式。
GenICam PFNC 文档解释了如何创建新的像素格式。GenICam 委员会维护了一份文档，其中列出了分配给每个像素格式的 32 位值。请注意，由 GenICam 像素格式值文档定义的其他像素格式，以及自定义像素格式，也可以由 GVSP 发射机或 GVSP 接收器使用。它不受上表中列表的限制。
对于 32 位像素格式 ID 值，可以按照 GenICam 像素格式文档 GenICam 像素格式值文档中列出的规则来实现自定义像素格式。这是通过将 pixel_format 的最重要位设置为1，并使用剩余的 31 位作为特定于制造商来实现的。自定义像素格式只能在不存在标准像素格式时使用，因为它们阻止了互操作性。
3.1 Mono1p
这种像素格式定义了一个 1 位单色、无符号、8 个像素打包的一个字节格式。有关其他信息，请参阅像素格式命名约定。必须将总图像有效载荷的最后一个数据字节填充到最近的 8 位边界。因此，如果图像宽度不是 8 个像素的倍数，则在图像的每一行的末尾不添加填充物。
#define MV_GVSP_PIX_MONO 0x01000000 #define MV_GVSP_PIX_OCCUPY1BIT 0x00010000 #define MV_GVSP_PIX_MONO1P (MV_GVSP_PIX_MONO | MV_GVSP_PIX_OCCUPY1BIT | 0x0037)
3.2 Mono2p
这种像素格式定义了一个 2 位单色、无符号、4 个像素打包的一个字节格式。有关其他信息，请参阅像素格式命名约定。总图像有效负载的最后一个数据字节必须填充到最近的 8 位。因此，如果图像宽度不是 4 个像素的倍数，则在图像的每一行的末尾不添加填充物。
#define MV_GVSP_PIX_MONO 0x01000000 #define MV_GVSP_PIX_OCCUPY2BIT 0x00020000 #define MV_GVSP_PIX_MONO2P (MV_GVSP_PIX_MONO | MV_GVSP_PIX_OCCUPY2BIT | 0x0038)
3.3 Mono4p
这种像素格式定义了一个 4 位单色、无符号、2 个像素打包的一个字节格式。有关其他信息，请参阅像素格式命名约定。总图像有效负载的最后一个数据字节必须填充到最近的 8 位。因此，如果图像宽度不是 2 个像素的倍数，则在图像的每一行的末尾不添加填充物。
#define MV_GVSP_PIX_MONO 0x01000000 #define MV_GVSP_PIX_OCCUPY4BIT 0x00040000 #define MV_GVSP_PIX_MONO4P (MV_GVSP_PIX_MONO | MV_GVSP_PIX_OCCUPY4BIT | 0x0039)
3.4 Mono8
此像素格式定义了一个 8 位单色、无符号、非打包的格式。有关其他信息，请参阅像素格式命名约定。
#define MV_GVSP_PIX_MONO 0x01000000 #define MV_GVSP_PIX_OCCUPY8BIT 0x00080000 #define MV_GVSP_PIX_MONO8 (MV_GVSP_PIX_MONO | MV_GVSP_PIX_OCCUPY8BIT | 0x0001)
3.5 Mono8s
此像素格式定义了一个 8 位单色、有符号、非压缩的格式。有关其他信息，请参阅像素格式命名约定。
#define MV_GVSP_PIX_MONO 0x01000000 #define MV_GVSP_PIX_OCCUPY8BIT 0x00080000 #define MV_GVSP_PIX_MONO8_SIGNED (MV_GVSP_PIX_MONO | MV_GVSP_PIX_OCCUPY8BIT | 0x0002)
3.6 Mono10
此像素格式定义了一个 10 位单色、无符号、非打包的格式。有关其他信息，请参阅像素格式命名约定。
#define MV_GVSP_PIX_MONO 0x01000000 #define MV_GVSP_PIX_OCCUPY16BIT 0x00100000 #define MV_GVSP_PIX_MONO10 (MV_GVSP_PIX_MONO | MV_GVSP_PIX_OCCUPY16BIT | 0x0003)
GIGE 协议摘录 —— GVSP 协议（三）（下）：https://developer.aliyun.com/article/1598405
