5. 触觉的负载格式 (Payload Format for Haptics)
5.1. RTP 头部用法
RTP 头部在 [RFC3550] 中定义, 并在图 2 中表示. 除非下文另有说明, 图 2 中各字段的含义与 [RFC3550] 第 5.1 节中的含义相同.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp (TS) |
+---------------------------------------------------------------+
| Synchronization Source (SSRC) Identifier |
+---------------------------------------------------------------+
| Contributing Source (CSRC) Identifiers |
| .... |
+---------------------------------------------------------------+
Figure 2: RTP Header for Haptics
Marker bit (M): 1 bit. 在一段触觉静默之后的第一个非静默 RTP 数据包中, marker bit 应当设置为 1. 这使得抖动缓冲区能够进行适配, 并使触觉设备在突发开始前执行 washout, 即复位到中立位置, 同时对最终用户体验质量的影响最小. 所有其他数据包中的 marker bit 必须设置为 0.
Timestamp (TS): 32 bits. 时间戳表示 RTP 负载中 MIHS 单元第一个样本的采样时间. 时钟频率必须设置为已编码触觉数据的采样率, 并通过带外方式传递, 例如作为 SDP 参数.
5.2. 负载头部
RTP 负载头部位于 RTP 头部之后. 图 3 描述触觉的 RTP 负载头部.
+-+-+-+-+-+-+-+-+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|D| UT | L |
+-+-----+-------+
Figure 3: RTP Payload Header for Haptics
D (Dependency): 1 bit. 该字段指示 RTP 负载中包含的 MIHS 单元是依赖单元 (值为 1) 还是独立单元 (值为 0).
UT (Unit Type): 3 bits. 该字段指示 RTP 负载中包含的 MIHS 单元类型. UT 字段取值见表 1.
L (MIHS Layer): 4 bits. 该字段是一个整数值, 表示 RTP 负载中包含的 MIHS 单元的优先级顺序. 该顺序由触觉发送方, 例如触觉编解码器, 根据应用特定需求确定. 例如, 发送方可以使用 MIHS layer 来优先传输对最终用户体验影响最大的感知内容. 0 对应最高优先级. 单个 MIHS layer 的语义未在本文档中规定, 留给应用程序分配. 如果发送方不使用 L 字段表示 MIHS 单元的优先级顺序, 则 L 值为 '0'.
5.3. 负载结构
本规范规定三种不同类型的 RTP 数据包负载结构. 单单元数据包在负载中包含一个 MIHS 单元. 分片单元包含一个 MIHS 单元的子集. 聚合数据包在负载中包含多个 MIHS 单元. 如表 1 所示, RTP 负载头部中的 unit type (UT) 字段同时标识负载结构, 并且在单单元结构中标识负载中存在的 MIHS 单元类型.
+===========+===================+==========================+
| Unit Type | Payload Structure | Packet Type Name |
+===========+===================+==========================+
| 0 | N/A | Unassigned |
+-----------+-------------------+--------------------------+
| 1 | Single | Initialization MIHS Unit |
+-----------+-------------------+--------------------------+
| 2 | Single | Temporal MIHS Unit |
+-----------+-------------------+--------------------------+
| 3 | Single | Spatial MIHS Unit |
+-----------+-------------------+--------------------------+
| 4 | Single | Silent MIHS Unit |
+-----------+-------------------+--------------------------+
| 5 | Aggr | Single-Time Aggregation |
| | | Packet (STAP) |
+-----------+-------------------+--------------------------+
| 6 | Aggr | Multi-Time Aggregation |
| | | Packet (MTAP) |
+-----------+-------------------+--------------------------+
| 7 | Frag | Fragmentation Unit |
+-----------+-------------------+--------------------------+
Table 1: Payload Structure Type for Haptics
负载结构如图 4 所示. 单单元负载结构在第 5.3.1 节中规定. 分片单元负载结构在第 5.3.2 节中规定. 聚合数据包负载结构在第 5.3.3 节中规定. 这些小节图中的 padding 指 [RFC3550] 中定义的 RTP padding.
+-------------------+
| RTP Header |
+-------------------+
| RTP Payload Header|
+-------------------+ | (UT = Aggr) |
| RTP Header | +-------------------+
+-------------------+ +-------------------+ | MIHS Unit 1 Size |
| RTP Header | | RTP Payload Header| +-------------------+
+-------------------+ | (UT = Frag) | | MIHS Unit 1 |
| RTP Payload Header| +-------------------+ +-------------------+
+-------------------+ | FU Header | | MIHS Unit 2 Size |
| RTP Payload | +-------------------+ +-------------------+
| (Single MIHS unit)| | RTP Payload | | ... |
+-------------------+ +-------------------+ +-------------------+
(a) single unit (b)fragmentation unit (c) aggregation packet
Figure 4: RTP Transmission Modes
5.3.1. 单单元负载结构
在单单元负载结构中, 如图 5 所示, RTP 数据包包含 RTP 头部, 后跟负载头部和一个单独的 MIHS 单元. 负载头部遵循第 5.2 节描述的结构. 负载包含 [ISO.IEC.23090-31] 中定义的 MIHS 单元.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Payload Header | |
+---------------+ |
| MIHS Unit Data |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |...OPTIONAL RTP Padding |
+-------------------------------+-------------------------------+
Figure 5: Single Unit Payload Structure
5.3.2. 分片单元负载结构
在分片单元负载结构中, 如图 6 所示, RTP 数据包包含 RTP 头部, 后跟负载头部, Fragmented Unit (FU) 头部以及一个 MIHS 单元分片. 负载头部遵循第 5.2 节描述的结构. 负载头部 UT 字段的值为 7. FU 头部遵循图 7 描述的结构. 在分片情况下, 所有 RTP 负载头部字段必须在所有分片中保持不变.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Payload Header | FU Header | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| MIHS Unit Fragment |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |...OPTIONAL RTP Padding |
+-------------------------------+-------------------------------+
Figure 6: Fragmentation Unit Payload Structure
FU 头部用于将单个 MIHS 单元分片到多个 RTP 数据包中. 同一 MIHS 单元的各分片必须按连续顺序发送, RTP 序列号递增, 并且在第一个分片和最后一个分片之间, 同一 RTP 流中不得发送其他 RTP 数据包. FU 禁止嵌套, 即 FU 禁止包含另一个 FU 的子集.
图 7 描述 FU 头部, 其中包括以下字段:
+---+---+---+---+---+---+---+---+
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
+---+---+---+---+---+---+---+---+
|FUS|FUE| RSV | UT |
+---+---+-----------+-----------+
Figure 7: Fragmentation Unit Header
FUS (Fragmented Unit Start): 1 bit. 对第一个分片, 该字段必须设置为 1. 对其他分片, 该字段必须设置为 0.
FUE (Fragmented Unit End): 1 bit. 对最后一个分片, 该字段必须设置为 1. 对其他分片, 该字段必须设置为 0.
FUS=1 且 FUE=1 的组合禁止出现. 这类数据包无效.
RSV (Reserved): 3 bits. 发送方必须将这些 bit 设置为 0, 接收方必须忽略这些 bit.
UT (Unit Type): 3 bits. 该字段使用表 1 中定义的值, 指示该分片所属 MIHS 单元的类型.
在 RTP 中使用 MIHS 单元分片意味着媒体接收方可能收到部分分片, 但没有收到其他分片. 丢失的分片通常不会由 RTP 重传. 这会产生部分接收的 MIHS 单元, 解码应用程序可以根据实现选择丢弃或使用这些单元. 如果带有 FUE 和 FUS 的连续分片丢失, 接收方可能能够检测出周围分片属于另一个部分接收的 MIHS 单元, 例如 UT 字段保存了不同的值.
5.3.3. 聚合数据包负载结构
在聚合数据包中, 如图 8 所示, RTP 数据包包含 RTP 头部, 后跟负载头部, 并且对于每个被聚合的 MIHS 单元, 包含一个 MIHS 单元大小字段和后续 MIHS 单元. 负载头部遵循第 5.2 节描述的结构.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|RTP Payl. Head.| MIHS Unit 1 Size | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| MIHS Unit 1 |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MIHS Unit 2 Size | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| MIHS Unit 2 |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |...OPTIONAL RTP Padding |
+-------------------------------+-------------------------------+
Figure 8: Single-Time Aggregation Packet
图 8 展示 Single-Time Aggregation Packet (STAP), 它可用于传输对应同一时间戳的多个 MIHS 单元. 例如, 如果同一内容使用两个频率, 它们可以在一个 STAP 中一次性传输. 多个 spatial units 也可以一起在 STAP 中发送, 因为这种触觉数据与时间无关. MIHS unit length 字段为 16 bits, 保存紧随其后的 MIHS 单元的长度, 单位为字节. 负载头部 UT 字段的值为 5.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|RTP Payl. Head.| MIHS Unit 1 Size | TS Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS Offset | |
+-+-+-+-+-+-+-+-+ |
| MIHS Unit 1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MIHS Unit 2 Size | TS Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MIHS Unit 2 |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |...OPTIONAL RTP Padding |
+-------------------------------+-------------------------------+
Figure 9: Multiple-Time Aggregation Packet
图 9 展示 Multi-Time Aggregation Packet (MTAP). 它用于在一个 RTP 数据包中传输多个具有不同时间戳的 MIHS 单元. 在可以接受一定延迟的环境中, multi-time aggregation 可以帮助减少数据包数量. 负载头部 UT 字段的值为 6. MIHS unit length 字段为 16 bits, 保存紧随其后的 MIHS 单元的长度, 单位为字节. timestamp offset 字段 (TS offset, 16 bits) 存在于 MTAP 情况中, 且必须设置为 (MIHS unit 的时间 - 该数据包的 RTP timestamp). 最早聚合单元的 timestamp offset 必须始终为零. 因此, MTAP 的 RTP timestamp 与最早的 MIHS unit time 相同.
5.4. MIHS 单元传输和接收注意事项
以下注意事项适用于通过 RTP 流式传输 MIHS 单元.
MIHS 格式支持可变时长单元, 并使用 initialization MIHS units 来声明后续非零时长 MIHS 单元的时长以及该时长的最大变化范围. 对于 RTP 流式传输, 发送方应当在 initialization MIHS units 中设置恒定或低变化的时长, 例如低于播放缓冲区的变化范围. 这样接收方可以较早判断单元是否丢失, 例如使用计时器, 并使解码器对 RTP 数据包丢失更健壮. 如果发送方发送具有高时长变化的 MIHS 单元, 接收方可能需要等待较长时间, 例如时长变化范围的上界, 才能判断某个 MIHS 单元是否在传输中丢失. 这种行为是否可接受取决于应用, 应用可以配置编码器生成具有适当长度变化的 MIHS 单元.
MIHS 格式使用 silent MIHS units 来表示触觉静默. 发送方可以决定不发送 silent units, 以节省网络资源. 从接收方角度看, 缺失的 MIHS 单元可能来自未发送的 silent unit, 也可能来自丢失的数据包. 因此, 发送方可以在触觉静默开始时发送一个或少量 MIHS silent units. 如果媒体接收方收到 MIHS silent unit, 接收方应当假定静默会持续到收到非静默 MIHS 单元为止. 这可以减少解码器对 RTP 数据包丢失的误检次数.
在使用 RTP video mixer 的某些多媒体会议场景中, 例如添加或选择新源时, 推荐将 Full Intra Request (FIR) 反馈消息 [RFC5104] 与触觉一起使用. FIR 消息的目的是使编码器尽早发送解码器刷新点. 在触觉上下文中, 合适的解码器刷新点是 initialization MIHS unit. initialization MIHS unit 点使解码器能够复位到已知状态, 并解码其后的所有 MIHS 单元.