“易 +”开源计划丨基于标准 WebRTC 低延迟直播开源实践
自上世纪末，流媒体直播技术兴起以来，伴随着网络基础设施的发展脚步，直播也同频共振般地起势。而近年来 AI、云计算、音视频等技术日趋成熟，以及新冠肺炎疫情带来的“宅经济”刺激，使直播行业的发展势头被进一步激活。
通过网络直播，你可以轻松观看到大洋彼岸正在进行的紧张体育赛事，也可以足不出户就阅尽祖国的大好河山、日出日落，甚至与 6000 万陌生人一起“云监工”火神山医院建设进度，为疫情防控力量点赞。
直播是个好东西，但，直播延时并不是。
或许你曾熬夜守在电商直播间，在秒杀倒计时中，因延时被人捷足先登；也或许在上网课时，因延时错过了重要的知识点；还或许在体育比赛关键时刻，因延时被提前“剧透”了结果。
凡此种种的破坏性体验，皆是「延时」惹的祸，市场对低延时的直播方案提出了需求。
在介绍低延时直播方案前，我们先来看看当下典型的直播架构。
一.典型的直播架构
在典型直播架构中，左边是推流客户端，协议上才采用 RTMP 上行。右边是拉流客户端，支持不同的拉流协议拉流，比较常见的是：RTMP、FLV,、HLS。
现有架构的优点
这套框架很好的利用了 CDN 厂商或者说云厂商的能力。尽管拉流协议没有统一，但由于 rtmp/flv/hls 等拉流协议是比较成熟的流媒体协议，经过多年的发展，各家 CDN 厂商广泛支持。在云端能力的支持下，服务端并发能力和拉流端加速能力大大增加了，直播行业蓬勃发展。
二.低延迟直播的现状
直播行业里卡顿和延迟就像是天平的两端。延迟做的越短，卡顿越高。延迟越长，卡顿越少。
一般场景下都是客户端用更大的 buffer 时长，牺牲延时来满足流畅性。随着行业的发展，在某一些应用场景对延时时间的要求越来越苛刻，比如体育比赛直播，教育场景下老师学生互动等，这时候现有常见的直播流媒体协议的缺点就体现出来了。
一般 rtmp 协议直播延时在 3-10s，如果经过层层 CDN 的缓存和转发，超过 10 秒也是常有的事，flv 和 hls 协议的延时更高。就拉流端来说，延迟很大一部分源自网络传输：
rtmp 在传输媒体前的 tcp 3 次握手和 c0/c1/c2 握手协议，无端引入了好几个 RTT 的延迟；由于 rtmp/flv/hls 的传输层都是基于 tcp 协议的，在网络不稳定的情况下，受限于 tcp 协议的拥塞控制不能充分利用网络带宽，客户端为了保持流畅性，只能加大缓存时间，更进一步加大了延迟。
其实认识到现有流媒体直播协议的局限性，各大友商也纷纷推出了自己的低延时直播，也比较好的起到了对抗弱网和加快首屏的作用。
但目前大家大都基于私有的信令协议和基于私有的 UDP 的流媒体传输协议，各大云厂商没法互相兼容，这就限制了低延迟直播的大规模发展。
三.基于标准 WebRTC 的低延迟直播开源实现
我们在探索如何能做一个开放的低延时直播方案，将来各家云厂商也能够比较方便的实现，就像现有 rtmp/hls 协议一样，推动整个直播行业低延迟化。
要实现这种方案需要做两件事情：
开放的信令协议
信令协议需要满足绝大多数厂商的媒体协商需求，同时又能尽可能的简洁。
开放的媒体协议
媒体传输协议需要满足在各大厂商之间有通用性的，在这之上的 QoS 能力也需要是开放的，而不能是私有的。
依据上面的要求我们选择了 RTC 领域成熟的解决方案：WebRTC。下图就是我们现在的实践架构。
上图中 WE-CAN 是云信的全球加速 RTC 大网，媒体在 Server 间的网络传输依赖 WE-CAN。
边缘媒体服务器从 CDN 拉流到 WE-CAN 大网边缘节点，再从 WE-CAN 大网边缘节点发送给客户端。
3.1 开源的信令协议实现
信令协议上采用：HTTP+SDP 的方式。
即客户端 POST 一个 SDP Offer
然后媒体服务器经过协商返回 SDP Answer。
3.2 标准的 WebRTC 媒体协议
客户端拿到 SDP Answer 以后，就是标准的 WebRTC 媒体交互流程：ICE，DTLS 加密连接，接收 RTP 流媒体。
下面是一个基本的 Web 端的拉流代码 Demo：
3.3 开源的 Native 媒体播放器
为了让 Native 客户端能够更加方便的接入 WebRTC，我们同样开源了一个集成了标准 WebRTC 的低延迟直播播放器：We-Can-Player，输入流地址，就能实现接收 WebRTC 流播放。
客户端的架构：
开源地址：https://github.com/GrowthEase/LLS-Player
只要厂商实现了类似的协议，用这个播放器稍作修改就可以拉到 WebRTC 的流。从架构上可以看到：媒体服务器和拉流客户端之间交互大都是基于标准的 WebRTC，没有私有的 RTP 扩展和私有的 QOS 协议，CDN 厂商甚至可以没有自己的 RTC 大网，只需在 CDN 边缘节点实现自己的标准的 WebRTC 网关+一个简单的 HTTP Server 就可以拥有同样的能力。
为了优化直播体验，我们还在 Server 端做了大量的优化。
四.优化直播体验
4.1 首屏时间优化
GOP 缓存首屏优化
假设用户推流端的 GOP 是 5 秒，在某些情况下，拉流端需等待接近 5 秒才能收到第一个 I 帧，首屏才能开始渲染。这对强互动性直播场景来说是不可接受的。
网易云信的解决方案是在媒体服务器里进行 GOP 缓存，缓存最近 1-2 个 GOP 的媒体包在 Server 端。当客户端和媒体器媒体连接成功后，先发送 GOP 缓存里的媒体包，再发送当前的媒体数据。客户端在收到媒体包后，需要根据一定的策略对齐音视频包，再加速追帧。
在具体的实践过程中，需注意 GOP 缓存大小、客户端的 Jitter buffer 大小的配合、GOP 缓存里音视频的对齐、不同的推流端不同 GOP 长度的适配等情况。
Pacer 平滑发送
如果推流端设置的 Gop 比较大，当拉流客户端媒体连接成功后，一股脑的给客户端发送全部的 Gop 里数据，可能造成客户端缓冲溢出以及其他问题。这时候就需要 Server 的 Pacer 平滑发送发挥作用了。
具体的实践过程中，要注意 Pacer 追帧速率和客户端追帧速率的配合。
4.2 延迟优化
WE-CAN 全球智能路由网络
直播行业之所以能够蓬勃发展，在技术方面，CDN 厂商的云端能力起到了很大的推动作用。CDN 加快了边缘节点的回源速度，边缘节点又加快了拉流终端的接入速度。
为了加快回源速度，回源媒体服务的选择会尽可能接近 CDN 的区域中心节点；为了优化客户端的接入性能，拉流媒体服务器也要尽可能的接近拉流客户端，因此媒体如何迅速地从回源媒体服务传输给拉流媒体服务就至关重要。
WE-CAN 很好地承担起了职责。作为网易云信自研的大规模分布式传输网络，WE-CAN 通过对各种资源智能调度，来实现全球任意两个媒体服务器之间的快速、稳定传输。WE-CAN 起到了对比传统 CDN 更迅捷，更稳定，更智能，覆盖范围更广的加速传输的作用。
4.3 卡顿率优化
网易云信支持标准 WebRTC 媒体流接入，并通过深度优化 GCC，ARQ，FEC，RED 等各类 QoS 策略达到自适应匹配各种复杂网络的能力，在 40% 丢包的情况下，依然能流畅直播。
4.4 全链路延时监控
如何全链路的监控拉流测引入的延迟？媒体流在 WE-CAN 大网里经过层层转发，如果任何一段路由引入不必要的延迟，就会影响最终的低延迟效果。我们的做法是在 RTP 头里加上一个 extension，记录 RTP 包到达每个机器的毫秒级的 NTP 时间，最后在转发给客户端的最后一个媒体服务器上汇报每跳路由的时间消耗以及边缘服务器和客户端之间的 RTT 时间，在最终发给客户端的客户端的 RTP 里再剥掉这个 extension。尽管各个机器的 NTP 时间没有绝对对齐，但依赖 WE-CAN 大网的全局 NTP 时间同步功能，差距控制在 1ms，这个精度足够在工程实践中发挥监控作用。
五.效果和后续工作
第一阶段在网络 QoS 方面暂时只支持 ARQ 和 Opus 的 inband-FEC 能力。由于 WebRTC 原生支持的基于 XOR 的 FEC 能力，在抗连续丢包方面很弱，所以暂时没有开启 FEC，但较 RTMP 有了巨大的改进。实现了 1 秒左右的延迟，200~400ms 的首屏，0.5% 以下的卡顿。在 40% 丢包情况下，依然能流畅直播。
我们后面的计划包括：加入包括 FEC 在内的更多的 WebRTC 标准 Qos 能力，推流测的 WebRTC 改造等。
网易智企【易+】开源计划已正式发布网易云信低延时直播方案。
查看网易云信低延时播放器源代码等：
https://github.com/GrowthEase/LLS-Player
https://gitee.com/GrowthEase/lls-player
其他已开源项目：
网易会议开源代码：
版权声明: 本文为 InfoQ 作者【网易智企】的原创文章。
原文链接:【http://xie.infoq.cn/article/c42818b99f6674ba9f7cf1bcd】。文章转载请联系作者。
网易智企是网易旗下一站式企业服务提供商。 2022.05.09 加入
网易智企是网易旗下一站式企业服务提供商，包含网易易盾、网易云信、网易云商三大业务板块。
评论