使用 RIST 的同步多流传输

2022-05-25 14:50:08 浏览数 (1)

来源：VSF 2022(The Video Services Forum) 主讲人：Ciro Noronha(Cobalt Digital) 内容整理：彭峰 许多应用程序需要同步内容解码,更具体地说，有许多视频源(通常是摄像机)，它们的内容需要使用编码器传输到同等数量的远程解码器。在解码器，播放需要同步——在解码器中一起到达的帧需要在解码器中一起出来。本文说明了一种基于 RIST 的解决方案。

目录

  • 问题背景
  • 基于 RIST 的解决方案
  • 系统细节
    • 实现步骤
    • TR-06-4 Part 1 和 RFC 3550 的差异
    • SR 数据包的生成
  • 效果展示
  • 存在问题

问题背景

现实生活中的一些流媒体应用场景可能有一些特性，在系统中有 N 个编码器，可能并不处于同一地理位置；有 M 个解码器，可能并不处于同一地理位置，且 M > N；编码器和解码器之间通过互联网连接。在这种系统中，每个编码器在同一时刻获取到的视频帧被要求在同一时刻被解码器解码播放。体育赛事转播和教堂礼拜就是这样的例子。

如下图所示，在许多的体育赛事中，为了高质量视频转播，通常会在不同的位置放置许多摄像机，在比赛转播时进行切换。在如此的场景下，摄像机之间的同步是非常重要的，即不同摄像机拍摄到的画面需要同时送到编码器，如果这一过程不是同步，例如在球员进球时，如果为了更好的观看角度切换摄像机画面后发现视频存在不同步，会造成广播的视频质量差，造成很大的用户体验下降。同理，当编码后的视频通过网络发送到广播室的解码器时，不同的视频源也需要同步。

Remote sports production场景下的多视频源同步

此外，在一些类似宗教活动的情景下，由于种种原因活动会分为主会场和分会场，通过多个编解码器，实现多个角度的视频传输，为了实现身临其境的感受，多个视频源之间的同步极其重要。

教堂场景下的多视频源同步

基于 RIST 的解决方案

可靠的 Internet 流传输(Reliable Internet Stream Transport, RIST ) 是一种开源、开放规范的传输协议，旨在通过有损网络（包括Internet）以低延迟和高质量可靠地传输视频。选择 RIST 的原因有以下几点：

  • RIST负责在IP网络(通常是Internet)上传输数据流;
  • 可以扩充RIST基础设施，以提供解码器同步;
  • 如果定义了通用方法，就可以实现多供应商互操作性。

目前的工作现状如下:

  • 技术工作完成;
  • 该方法已获得 AG 的批准；
  • TR正在被写入;
  • 如获批准，将作为 TR-06-4 第一部分发布。

TR-06-4 的内容大纲

实现多个视频源的同步的基本思想是为每个解码器提供足够的信息，以便它可以在同步缓冲区中添加额外的延迟，使所有解码器的端到端总延迟完全相同。如下图所示，系统中的延时来自几个部分，主要是编码延时、传输延时、协议延时（例如网络丢包重传引起的延时）、同步延时以及解码延时，在每个数据包中添加足够的信息，从而使得解码端在同步缓冲区为不同视频源的数据包设置不同时延，从而可以实现不同视频源之间的同步。

系统细节

实现步骤

为了实现上述的多源视频同步系统，具体的步骤如下：

  1. 编码器和解码器需要一个同步时钟，通常可以通过 NTP 协议实现，但是也不需要过于准确的时钟同步，只要保证误差在一帧内即可；
  2. 编码器需要为解码器提供接收的每一帧视频摄取时的 NTP 时间（因为视频的特性可以周期性设置 NTP时间）；
  3. 解码器在帧的 NTP 时间上添加一个固定的延迟，其表示该帧的播放时间，该固定延迟必须足够大，以适应特殊情况下的编码、网络和协议延迟。

RIST 协议能够符合上述的要求，RIST Simple Profile (VSF TR-06-1)要求使用周期性的 RTCP 发送者报告(Sender Report)包，在 TR-06-1 中，这些报文仅用于保持防火墙状态，以便 RTCP NACK 数据包可以返回。TR-06-1 不要求接收方解析 SR 数据包或处理其内容,并且如下图所示，SR 包已经包含同步所需信息。

RTCP Sender Report

TR-06-4 Part 1 和 RFC 3550 的差异

在 TR-06-4 的 Part 1 中，会对 SR 数据包的 NTP 时间戳部分做出一定的设定，相比于 RFC 3550，具体的差异如下表所示：

TR-06-4 Part 1

RFC 3550

需要NTP时间戳

NTP时间戳为可选项，可设置为零

NTP时间戳必须来自真实的NTP服务器

NTP时间戳可以是设备的wallclock

NTP时间戳对应于帧捕捉时间

NTP时间戳对应SR消息传输时间

RTP时间戳对应于携带帧的报文的时间戳

RTP时间戳与NTP时间戳对应的时间点相同

SR 数据包的生成

SR 数据包生成示意图如下，且通过周期例如每 100 ms 发送一个 SR 数据包即可实现同步。

SR 数据包生成

效果展示

下面两张图是系统中多个视频流播放初始状态和运行一段时间之后的状态，从图中的时间戳可以看到，视频同步的效果非常好。

系统初始状态图

系统运行一段时间后状态图

存在问题

  • 解码器有一个时钟恢复过程，将本地回放时钟锁定到传入 STC；
  • 由于 SDI 时钟漂移的要求，这是一个缓慢的过程；
  • 由于时钟恢复过程(可能是几十分钟)，解码器可能需要一些时间来实现同步；
  • 理想情况下，时钟恢复也应该与同步过程绑定在一起；
  • 解码器都需要手动配置相同的目标延迟，这需要足够大，以适应最坏情况下的延迟，但需要较大的缓冲区和引入不必要的时延。

附上演讲视频：

http://mpvideo.qpic.cn/0b2eniaamaaareae7hegwjrfa2wdazvaabqa.f10003.mp4?dis_k=39f020d14de8bd0e8234fdefd7b68ff4&dis_t=1653461375&vid=wxv_2405444018890702850&format_id=10003&support_redirect=0&mmversion=false

ntp unix

0 人点赞