真香警告！直播分发选低延迟 RTC 还是 CDN？

上个月，“冷门歌手”孙燕姿又一次占据热搜，她的直播演唱会开场短短 16 分钟，就收获过亿点赞。其实，孙燕姿并不是第一个尝鲜直播演唱会的。疫情以来，一切线上、云端的活动都已经是大家司空见惯的事情了。不仅是一众歌手纷纷办起了线上演唱会，音乐会、音乐节，甚至非常讲究现场感的话剧都开始采用直播的形式开展。

移动互联网把我们带向数字经济社会，而直播就是其中非常重要的工具。无论是经久不衰的娱乐直播，还是风靡一时的答题直播，直播都是这几年的流量担当。曾几何时的新鲜花样已经变成了互联网应用的标配，我们进入了“万物皆可直播”的时代。

那开发者要怎样实现一个直播应用呢？又要如何通过技术手段保障用户的使用体验？本文将结合融云在细分行业的深入研究和实践经验进行一一解答。

直播链路选择

简单来看，一个完整的直播应用实现原理是：主播端采集音视频，推到服务器，再由服务器分发给观众观看。

主播端负责推流，需要配置选用 RTC 链路分发直播画面或者用 CDN 链路分发。如果涉及连麦还需要考虑如何做 MCU 合流，观众订阅合流的好处是能保证多个主播对话是基本对齐的，不会出现因为网络差订阅多个订阅主播时某一主播画面卡顿或延迟造成“慢半拍”等现象。

影响用户体验的几个问题

直播平台的竞争核心，无论支点放在主播还是内容，都离不开应用本身“好不好用”的体验问题。从技术逻辑上看，直播要无限接近线下实时沟通，也就是要实现低延时、高流畅的交互。

而面对直播场景实现上如此复杂的链路选择和场景切换，直播应用常会遇到延迟、链路切换失败、首屏耗时长等导致用户给“差评”的问题，也是开发者需要重点思考的地方。

延迟问题

早期的直播应用一般都是单主播，只能通过文字与观众互动。当时业界对直播实时性要求也不高，软件开发者一般会选用 RTMP 推拉流，让直播画面在 CDN 链路上进行分发。这样主播和观众之间的延迟一般是 2～5s，也就是说：观众看到或听到的直播画面，声音是主播 2～5 秒之前发出的。

当主播与观众互动时，比如询问大家想听什么歌，得到反馈结果就要等较长时间。这种情况在电商直播中尤其影响整体效果，当主播发布商品让观众抢购时，会先出现购买入口，然后才听见主播的口播“商品已上架，快抢购”。这种错位的体验，实在谈不上优质。

想要解决这个问题，开发者必须选一个靠谱的 CDN 直播加速服务，或者干脆选择 RTC 服务做直播分发。在这方面，融云的 CDN 链路与国内头部厂商深度合作，共建互动直播场景的多场景、多链路切换；RTC 直播上，融云实现了主播到观众延迟在 500ms 以内的低延迟直播。

连麦时切换链路失败

如果使用 CDN 链路做直播分发，在连麦场景中观众切换为连麦主播时涉及从 CDN 链路切到 RTC 链路，终端则需要切换音视频播放器。开发者需要维护两个播放器的状态，经常出现黑屏、卡顿等问题。

融云在做这两个场景切换时充分考虑了各种异常情况，避免切换失败、黑屏等影响用户体验的问题；在使用融云 SDK 做直播时，单房间连麦、多房间连麦可以随时切换，主播还可以方便快捷地控制本房间的观众看到的画面样式。

首屏耗时长

随着网络技术和通信技术的发展，我们对于延迟的容忍度越来越低。而传统 CDN 链路涉及直播地址分发、请求数据等一些列耗时操作，无法满足用户对于“打开一个直播，希望立即加载出视频画面”的需求。

融云在做低延迟直播时充分考虑各种场景，整合各类数据接口，可以实现视频秒开，用户进直播间到视频加载只需 1 秒。

直播稳定性

在保证直播稳定性方面，融云自主研发的算法可以在主播侧保证主播推流的上行数据在弱网情况的可靠性。即使视频丢包 40%，音频丢包 80%，都不会中断直播业务。并且，主播的声音经 3A 处理和美声服务可以更优质地传输给观众。

观众侧无论订阅低延迟还是 CDN 链路都可以抗弱网，支持观众在网络差时切换为仅订阅音频，或者订阅更小尺寸的视频。

回过头来，我们再说说融云 CDN 的好处。首先，CDN 分发成本低，费用消耗往往比 RTC 链路低很多，非常利好价格敏感型项目；其次，借助融云遍布全球的服务节点，出海业务的跨国直播也能快速响应；最后，融云与各大 CDN 厂商都有合作，可以配合不同的项目需求进行调整链路，支持视频转码、加密等个性需求。​