眼动仪多流RTP传输咨询：单会话复用还是多会话传输？

核心背景 #

你方开发的科学嵌入式眼动仪需传输3路视频流（眼球、头部前方画面等）及计算生成的元数据（凝视点等），要求采用纯RTP协议（不使用RTSP/RTCP），当前纠结于是否将所有流复用至一个RTP连接，还是分开传输。以下结合RFC3550规范给出专业分析：

RFC3550 5.2章节（中文翻译） #

5.2 RTP会话复用

为提升协议处理效率，应尽量减少复用点，这符合集成层处理设计原则[10]。在RTP中，复用通过目的传输地址（网络地址+端口号）实现，每个RTP会话对应不同的目的传输地址。例如，由独立编码的音频和视频组成的电话会议，每种媒体应承载在独立的RTP会话中，使用各自的目的传输地址。

不同的音频和视频流不应承载在同一个RTP会话中，通过负载类型或SSRC字段进行解复用。将不同RTP媒体类型的数据包交织在一起且使用相同SSRC会引发诸多问题：

1. 假设两个音频流共享同一个RTP会话和SSRC，其中一个切换编码方式导致负载类型变更，将无法区分是哪个流发生了编码变更。
2. SSRC被定义为标识单一的时序和序列号空间。若交织多种负载类型，当媒体时钟速率不同时需要不同的时序空间，且需要不同的序列号空间来区分哪种负载类型出现了丢包。
3. RTCP发送者和接收者报告（见6.4节）每个SSRC仅能描述一个时序和序列号空间，且不携带负载类型字段。
4. RTP混音器无法将不兼容媒体的交织流合并为一个流。
5. 在一个RTP会话中承载多种媒体会导致：无法按需使用不同的网络路径或网络资源分配；无法按需接收部分媒体（例如带宽不足时仅接收音频）；接收端若想用独立进程处理不同媒体会受限，而使用独立RTP会话则支持单进程或多进程实现。

为每种媒体使用不同SSRC但发送至同一个RTP会话，可避免前三个问题，但无法解决最后两个问题。

另一方面，在同一个RTP会话中使用不同SSRC复用同一种媒体的多个相关源，是多播会话的常规做法。上述问题均不适用：例如RTP混音器可合并多个音频源，且所有源都适用相同的处理方式。在其他不涉及最后两个问题的场景中，使用不同SSRC复用同一种媒体的多个流也是合适的。

针对你场景的分析与建议 #

1. 对“独立媒体流”的定义解读 #

RFC中“独立媒体流”的核心判定依据是媒体类型是否相同以及是否需要独立的时序/序列号空间：

• 3路视频流属于同类型媒体（均为视频），即便来自不同传感器，也不属于RFC定义的“需独立会话”范畴；
• 元数据流（凝视点等）属于非视频的结构化数据，与视频属于不同媒体类型，需要独立的时序空间，属于“独立媒体流”。

2. 复用方案的可行性与限制 #

如果坚持复用：

• 可行部分：3路视频流可通过不同SSRC复用在同一个RTP会话中，完全符合RFC中“同类型媒体多源复用”的允许场景，不会触发规范中提到的核心问题；
• 需注意的问题：
  • 元数据流必须分配独立的SSRC，避免与视频流共享时序/序列号空间；
  • 需接受RFC提到的复用不同媒体类型的限制：无法为视频和元数据配置不同网络资源（如视频优先带宽、元数据优先低延迟）、接收端无法单独选择接收部分流、多进程接收实现复杂度高；
  • 由于你方不使用RTCP，RFC中关于RTCP报告的问题可忽略，但仍需保证每个SSRC对应独立的时钟和序列生成逻辑。

3. 分开传输的优势 #

若选择为视频流组、元数据流分别建立独立RTP会话：

• 完全符合RFC的最佳实践，规避所有复用带来的潜在限制；
• 可针对不同流定制传输策略（如视频流配置QoS优先级、元数据流调整发送频率）；
• 接收端扩展性更强：可灵活选择接收部分流，或用独立进程处理不同类型的流；
• 后续若需引入RTCP，无需修改整体架构，直接适配即可。

最终建议 #

• 推荐将3路视频流复用至一个RTP会话（使用不同SSRC），同时为元数据流单独建立一个RTP会话；
• 如果受限于嵌入式设备的端口或会话管理能力，必须将所有流复用，则需为每个流分配独立SSRC，并提前评估接收端的扩展需求（是否需要单独接收部分流、是否需要差异化网络配置），确保这些限制在你的应用场景中可接受。

内容的提问来源于stack exchange，提问作者Multisync