音视频传输协议众多， 5G 时代不同业务应该如何选择？

摘要：音视频传输协议众多， 不同业务应该如何选择？ RTSP、RTMP、RTP/RTC、HLS、MSS、DASH、WEBRTC、RIST、SRT；在此我们就从业务发展的视角来理解各种流媒体协议，帮助大家有更加清晰的理解，选择时做出更理性的判断。

音视频传输协议众多， 不同业务应该如何选择？ RTSP、RTMP、RTP/RTC、HLS、MSS、DASH、WEBRTC、RIST、SRT；在此我们就从业务发展的视角来理解各种流媒体协议，帮助大家有更加清晰的理解，选择时做出更理性的判断。

IPTV

IPTV 是由运营商主导建设的一套系统，他的主要对标对象是传统广电的数字电视。所以这套系统首要解决的是大规模直播的问题，在此基础上还需要支持点播、时移、回看等新业务。运营商的优势就是可以自建一套可管理的网络，所以直播就基于组播技术进行大规模分发。主要技术栈是 RTP+TS over multicast，这个技术大大降低了直播峰值对流媒体服务器的压力。而点播、时移、回看业务由于必须使用单播传输，所以当时选择的技术栈是使用 RTSP 进行流媒体控制，使用 RTP+TS over UDP（少量基于 TCP）进行数据传输。

现在这套系统服务了全国接近 1.7 亿多用户。这套技术栈面临的挑战和对应的解决方案主要包括几点：

解决单播基于 UDP 传输丢包的问题，丢包会导致用户观看花屏或爆音，我们基于 RTSP 协议扩展制定了一套规范，基于 RTSP 的 GET_PARAMETER 扩展了重传数据报文的信令，主要是基于 NACK 原理进行设计，通知流媒体服务器哪个报文没有接收到，流媒体服务器根据请求中携带的 RTP 序号进行重发。

解决组播传输丢包问题，组播报文丢包会导致直播花屏或爆音，我们采用了 2 个手段解决这个问题：

• FEC

• ARQ

通过 FEC 技术增加等步长的冗余报文，可以解决随机丢包问题，但是无法解决突发连续丢包问题，这个时候就需要 ARQ 技术，我们在系统中增加一个 RETServer，RET Server 也会加入组播组接收和机顶盒收到的相同的组播报文，机顶盒在检测到丢包后，会向这台服务器发起 NACK 报文，RET Server 收到请求后根据请求的 RTP 需要将对应的报文发送给机顶盒。

解决组播传输下频道快速启动问题，终端加入组播组的时间是随机的，无法保证每次加入组播组后接收到的报文就可以理解用于解码并显示，所以我们通过在系统中增加一个 FCC Server，解决该问题，终端在起播观看一个频道的时候，优先向 FCC Server 请求一条单播流，FCC Server 会以 1.X 倍的速率将 I 帧和解码所需的报文发给终端，配合终端快显技术可以实现 300ms 以内的频道切换速度。

IPTV 多屏

随着移动终端的发展，运营商希望在 IPTV 业务基础上，发展手机等多屏业务，开始支持 HLS（主流）、MPEG DASH（部分海外运营商，支持 MultiDRM）流媒体协议。这套系统在流媒体协议层面临的问题是不同屏幕，不同 DRM 格式，多种格式带来了存储空间成倍的上升，特别是 NPVR 个人录制业务，对存储的需求非常大。主要解决思路就是 JITP（Just In Time Package），即只要存储一份内容，根据用户观看的内容格式进行实时格式转换。

OTT 点播

伴随着以 Youtube，Netflix，爱奇艺，优酷，腾讯视频为代表的 OTT 视频点播平台的崛起，以及苹果手机的普及和 HLS 协议的出现，流媒体协议从 HTTP 渐进式下载发展到 ABR Streaming，HLS 是其中最为主流的一种 ABR 协议，HLS 也成为了各个 OTT 视频平台的首选视频传输协议。这套系统在流媒体协议层面临的问题和解决方案如下：

1、 解决基于互联网的大规模分发问题。CDN 技术可以很好的解决这个问题，这也是 OTT 流媒体协议基本上在设计之初就考虑对 CDN 友好的原因。

2、 Netflix 由于业务量的规模发展到一定规模，从最开始选择第三方 CDN，走向了自建 CDN（Open Connect）的道路，但是他的技术栈依旧是 HLS 和 DASH 这类对 CDN 友好的流媒体协议。

OTT 直播

细分为事件类（新闻/ 赛事/ 演唱会）直播、个人（游戏/ 网红/ 秀场）直播。满足这类直播业务的流媒体协议层面临的问题和解决方案如下：

1、首先他们和 OTT 点播一样，需要解决基于互联网的视频大规模分发问题。

2、其次直播相较于点播需要额外考虑的一点就是直播时延，第一类：电视台/ 事件（新闻/ 赛事/ 演唱会）直播基本没有和观众互动的要求。所以它们依然选择对 CDN 友好的 HLS 和 DASH 协议，但是时延会高达 10-30s，随着 CMAF 格式的出现，根据我们在实验室的测试数据表示时延可以小于 5s。第二类：个人（游戏/ 网红/ 秀场）直播，以国内直播平台为例，商业模式主要靠打赏分层，所以要求直播的 E2E 时延必须低于 5s，否则观众与主播的互动效果非常差，直接影响直播平台的收入。这类厂家选择的技术栈为延迟更低的 RTMP 和 HTTP FLV。

3、随着手机和 4G 网络的普及，部分主播也开始尝试在户外进行开播，由于户外直播的网络条件不可控，而 RTMP 是基于 TCP 传输的，导致在户外 4G 网络条件不稳定的环境下，直播效果很差，所以针对弱网环境下的直播上行效果差成为直播平台需要解决问题。为了解决这个问题，大家把眼光转向 UDP，基于 UDP 的直播传输技术逐步进入人们的视野。常见的有 ZIXI、SRT 和 RIST。ZIXI 属于纯商业化公司，显然不合适大量个人直播上传这类商业模式的直播平台。SRT 有相对成熟的开源社区支持，所以在国内应用较为普遍。RIST 是由 Video Services Forum (VSF)于 2017 年初开始制定的可靠的互联网流传输协议（Reliable Internet Stream Transport，RIST），相较于 SRT，基于 UDT 非实时流媒体的技术栈构建，RIST 一开始便使用较为成熟的 RTP+RTCP 技术，而且他只定义了标准化的语法，允许实厂家在此基础上进行创新，而又不影响互相操作。经过近几年的发展 RIST 支持的场景越来越多，也越来越成熟。

4、直播业务发展越来越繁荣后，又出现了多主播 PK，主播与观众连麦等场景，这些对时延的要求直接从 5s 变成 1s 以内， 甚至小于 400ms， 为了满足业务的发展，直播平台选择了实时通信的技术栈 RTP+RTCP over UDP。一旦引入 UDP，就需要解决丢包带来的视频体验问题，这里常见的技术有 FEC、ARQ 等。

实时音视频 RTC

随着 5G 网络的普及，以及疫情带来的影响，人们对实时音视频技术的应用场景会越来越多，主要包括：会议、连麦、音视通话、视频通话、在线教育、远程医疗等。由于这些应用场景对时延的要求<400ms，所以从技术栈选择来看，基本上都是选择 RTP/RTCP over UDP 的方式进行音视频数据的输出。

如果把流媒体协议做三个维度划分：质量（画质/帧率）、平滑、延迟。实时音视频通信和 OTT 直播上传场景相比，对低质量的容忍度更高，即允许降低一定的质量，下降（降帧率等）来换取更加平滑的体验和更低的延迟。这个选择上的差异，导致在技术设计上需要打通网络传输系统和音视频编解码系统，实现根据网络传输质量实时动态调整音视频编码参数，在质量、时延、平滑三个维度上进行权衡得出最优解。

流媒体新的发展方向

1、 新的媒体表现形式包括 VR、自由视角、点云；他们与传统视频的最大区别在于，传统视频主要支持时间维度的定位，而新的媒体，除了支持时间维度的定位，还支持空间维度的定位。当前主要在 MPEG 标准组织中进行讨论，基于 MPEG DASH 规范进行演进。以 VR 为例，一般人类的 FOV 视场角<140°，新的流媒体协议利用这个特性，可以实现根据观众观看的视频范围，进行部分传输，从而降低的对带宽的诉求，这也很好的解决了传输的数据量越来越大对带宽要求苛刻的问题。华为云视频的 Cloud VR 产品已经支持 8K VR、自由视角的直播和点播服务。

2、 全互联实时音视频直播，随着在线教育和在线办公的普及，越来越多客户对具备大规模分发能力的低时延互动视频服务有着强烈的诉求，当前的架构要么支持大规模分发，要么支持低时延、互动，无法同时具备三者的能力。我们认为未来的主流架构需要同时满足这三样能力，华为的实时音视频服务已经完成这套架构的实现，致力于在流媒体领域持续深耕，让我们共建流媒体的未来。

点击关注，第一时间了解华为云新鲜技术~