行业的用户体验分析

互动直播场景中有主麦主播、辅麦主播、粉丝三个要素，这三者之间关系构成了直播间的各种互动场景。

1. 主麦主播、辅麦主播可以无障碍的进行音视频通话，通常延时在300ms以内；
2. （主麦、辅麦）主播与粉丝互动场景；主播说话，而粉丝以文字、图片、送礼物等方式进行互动；这种差别造成一次互动的延时在3000ms以上，想象一下如下互动场景：

• 进场特效播放完依然没有收到问候
• 当主播与粉丝一起玩“王者荣耀”时需要偷塔时，无法满足
• 当主播与主播PK时，其中一个主播最后几秒想拉票时；无法满足
• … … …

如何提升直播过程中三个要素之间的互动，让主播与主播之间、主播与粉丝之间达到一致的用户体验？优酷直播流媒体团队做了低延时流媒体技术的探索实践，实现了在用户体验不下降的基础上，让主播与主播延时<300ms,主播与粉丝延时<600ms，解决了直播间各类互动问题。

作茧自缚–传统解决方案

传统直播解决方案中主播之间以实时通信的方式传输延时小于300ms，但是主播与观众之间通过链路传输、CDN分发整个延时往往在3000ms左右；如下图：

从图上我们可以看到产生延时的主要原因就是RTMP传输链路、CDN环节、观众播放器缓存三个环节产生；如果想要提升用户的体验，就必然从这三个环节上做改动，尤其是CDN把持了传输链路环节，然而CDN不是你想改就能改的。

基于这样的分析我们可以得出这样的结论：

• 视频CDN大大减少了开发人员的工作量
• 你能做多好，取决于你控制的链路有多长
• CDN侧不可控，所以等待CDN的改变也遥遥无期
• CDN侧不可控，所以做一个和服务器交互的低延时播放器也没戏
• 传统的解决方案是一张温柔而又可怕的温床

蜕变之痛–低延时直播系统

针对上面的问题，我们解决方案简单粗暴：做一个全链路都可以控制的流媒体传输系统；如下图：

山重水复疑无路–项目挑战

想好就做，但是蛮干往往没有好结果；这个设计使用CDN的思想改造了整个实时通信系统，既兼顾CDN的大并发分发，又兼顾实时通信的低延时。无论是谈实时通信系统还是谈CDN都不是个小题目，何况两个融合的系统，这里面“水很深”、“坑很多”。

然而挑战还不止这些；实际的工程中，如何降低延时、如何保证流畅率往往有是相互矛盾的话题，降低延时就要降低播放侧buffer、服务侧的buffer，buffer变小，卡顿率就上升；而想流畅率上升就要增大buffer，增大buffer，延时就大；无论怎么调整buffer，问题都这里，如何解决呢？

柳暗花明又一村–解决方案

低延时直播系统根据具体业务需求，融合CDN、私有实时通信协议、WebRTC、云原生等技术完美解决了项目的各类苛刻要求；把问题模型转换为技术角度看：

延时的产生及可控性分析：

从上图我们可以看出来，可控的唯二也就是传输层、播放器buffer两部分了；在低延时项目中RDN系统控制了整个传输过程，优化了每一个细节，把延时降至118ms以内，低延时播放器自适应动态控制buffer大小、严格控制音视频加减速，保证流畅率的基础上又使延时在415ms以内；通过控制播放侧目标延时实现流畅优先、延时优先两种策略，满足主播连麦互动、粉丝互动两种业务场景。

CDN进阶为RDN系统

传统的CDN、视频会议系统可以自行查看网上的方案，RDN系统是一个融合CDN架构，并以视频会议媒体服务器为节点的系统；RDN在进行媒体传输采用懒加载的方式进行，当主播把流传输至接收的边缘节点，此时如果有观众播放流，会通过GSLB返回最近的边缘节点并进行资源的索引把流快速的下发至播放侧的传输SDK。媒体流的分发示意图如下：

唯快不破–传输延时如何降至最低

传输延时、播放侧延时是唯二可控的部分，且看我们如何把传输降到最低：

播放器进阶为低延时播放器

低延时播放器是系统中延时控制的重要环节，是系统中唯一延时可控且可调的部分；相比于传统播放器功能既要满足流畅率、秒开率、音画同步等用户指标，又要保证延时足够低；低延时播放器架构图：

用户体验第一-低延时场景下如何保证用户体验

低延时播放器通过定制优化后的neteq，抵抗网络的抖动、丢包等问题，显著提升弱网情况下的用户体验，通过滤波后的音画同步方案，保证在音视频快速加减速同时又能保证用户的体验。

扁鹊全链路监控系统

扁鹊系统收集端侧、服务器侧日志；不但整个链路的服务质量，也用于排查各类线上问题。

羽化之美–数据报告

在流畅率、秒开率不低于传统直播方案的场景下，互动延时指标大幅降低86%；系统自2017年稳定运行至今，为直播用户提供了低延时互动、点击即见、清晰、流畅的高质量互动直播间；稳定支撑了来疯秀场PK，低延时直播各类场景，保证了来疯两年多的各类比赛顺利进行。

回顾历史–我的思考

低延时直播系统是由传统直播技术、实时通信技术、WebRTC技术融合，专为互动直播而生的系统；达到了文字和音视频同步的效果，像“欢迎大哥”、“拉拉票”、“打他”这些欢迎、拉票等直播互动再也不需要等待；回顾整个系统的诞生，我的思想也在逐渐的变化，回想初次接触这三个技术：

• 传统直播技术 = RTMP、CDN、ijkplayer
• 实时通信技术 = MCU、SIP、RTP/RTCP
• WebRTC技术 = JSEP、P2P 、SFU、ICE、SDP、neteq

后来深入了解这些技术细节、互动直播业务的需求、开发过程中的痛点；开始思考可以用这些技术再往前走一步，自研一套低延时直播系统一劳永逸的解决这些问题；经过前期详细论证确定正确方向后，虽然过程困难重重，秉着“只要路对了就不怕远”、“只要精神不滑坡，方法总比困难多的”精神，最终还是安全的抵达了对岸。