标签：直播 基于 src pdb 提高 主题 介绍 构架 压力
作者：吴桐，网易云信音视频实时通话项目与互动直播项目负责人。先后参与网易UU网游加速器、易信音视频实时通话等项目，在高性能服务器、网络传输技术、实时音视频多媒体与直播技术各模块有资深的实践与经验。
一、前言
移动直播这把火从2015年一直烧到2016年，毫无疑问直播是当前移动互联网最热门的领域之一，在超大热度的引导下直播领域也吸引了大量的商业资本。在这各大直播应用万花齐放的时刻，也正是直播应用面临的真正风口。站在这个风口上，直播应用只把握好风向标，推出具备高用户粘性的差异化功能，才能在这个不断推陈出新的时代站稳脚跟，获得不可动摇的地位。
（移动直播火爆）
当前国内大多数的直播应用，使用的是单主播模式，主播与观众仅仅使用文字、点赞、礼物等方式进行互动。在主播直播时，观众如果能够与其进行实时的视频互动，给观众连麦露脸的机会，这将**提高用户的参与感与幸福感，增加用户粘性。而且市面上能够提供这种连麦互动直播功能的应用还非常少，这也将成为2016下半年各直播应用的主要竞争领域。
二、连麦互动直播是什么
为了更直观的阐述互动直播是什么，举个简单的例子：传统直播就像看“新闻联播”，观众只能收看这个节目，偶尔能通过手机短信发信息与节目组进行互动。当然现在基于互连网的直播已经先进得多，可以使用互联网发送文字、点赞、送礼物，消息的实时性也**提高，但本质上与看“新闻联播”的体验类似。
而互动直播就像到达芒果台快乐大本营的录制现场，观众坐在录制现场的观众席上，可以看节目，同时还有机会被邀请到台上和主持人互动，当然主持人可以邀请多名观众上台进行互动，而互动的内容其他观众也能看到。
连麦互动直播相比传统单向直播，给了观众更直接的参与感以及与主播音视频实时互动的满足感，对提升直播应用的活跃度和粘性都有明显作用。
三、连麦互动直播功能流程
（连麦互动直播功能流程图）
① 主播正常开始直播，普通观众看到主播的单人直播画面；
② 需要连麦的观众发起连麦请求，进入连麦申请列表；
③ 主播从连麦申请列表中选择一名或多名观众进行连麦操作，主播与连麦观众进行实时音视频互动，同时互动直播系统生成“合成画面”；
④ 普通观众看到直播画面为包含主播与连麦观众的“合成画面”；
⑤ 连麦结束，恢复主播单人直播模式。
四、连麦互动直播实现方案
接下来我们探讨一下连麦互动直播的具体实现方案，这部分将主要阐述互动实时性高且具备真实可行性的两种方案。这两种方案网易云信在项目中都有实践，下面会详细分析各自的优缺点。
为了实现互动实时性高的连麦，首先需要有一套实现了类似微信、Skype及Facetime的多人音视频实时通话系统。这套实时通话系统可以选择自主研发或者基于开源软件如：Google的WebRTC做二次开发，网易云信自主研发了一套基于私有协议的多人实时通话系统，下面简单介绍多人实时通话系统的一些重点技术细节。
① 多人音视频实时通话系统为了降低通话时延，我们使用UDP协议作为传输层协议，众所周知UDP协议是不可靠，为了提高弱网下的实时音视频的通话效果，需要使用相关方案来做QoS保障，主要包括：a)使用基于网络状态的音视频码率自适应算法，根据当前网络的丢包、时延自适应降低或者升高音频和视频的码率和帧率，通过这个方法来降低网络的拥塞，提高通话质量；b)使用智能Jitterbuf算法来平滑网络抖动，同时内部使用音频编码的丢包补偿（PLC）算法进一步提升通话质量；c)使用基于多层参考的视频编解码器，降低视频丢包后的卡顿；d)整个UDP传输层使用前向纠错FEC算法进行智能保护，最大限度上保证实时音视频通话的效果。根据我们的实际测试，在使用上诉QoS保障策略以后，音视频通话可以抗20%丢包和600ms的网络抖动。
② 多人音视频实时通话系统为了在保障质量的前提下尽量降低通话流量，音频编解码主要以Opus为主，Opus融合吸收了CELT和SILK编码的各种优点，具备高音质，高压缩率，高抗丢包等特性，非常适合移动网络。视频编解码我们使用OpenH264，OpenH264编解码性能优秀，同时具备：动态码率、动态帧率及时域分层等多项适合移动网络实时通话的特性。同时我们使用了自主研发的降噪算法，配合回声消除、自动增益和舒适噪音等音频处理算法来进一步保证音频的质量。
③ 现在用户对于视频的清晰度要求越来越高，我们的多人实时通话系统能够支持720p，720p下纯软件编解码对CPU开销过大，因此在可以开启硬件编解码的机器上，对于需要720p清晰度的都尽量使用硬件编解码。对于苹果手机硬件编解码基本上只与iOS的版本相关，而Android情况就会复杂得多，不仅与手机硬件相关，还和各个手机的ROM相关，为了解决这个问题需要去做适配。我们在网易强大的移动应用测试部门的配合下，为大多数的Android设备做了适配。
④ 没有覆盖全球的服务器部署与网络拓扑搭建，是不可能构架出一套完善的多人音视频实时通话系统的。依赖网易云在全球范围内的机房节点，我们搭建了多个多线接入网络拓扑，部署了高可用的服务器集群，并利用智能分配算法与路由策略，为跨省、跨运营商、跨国的多人实时通话提供优质的传输通道。
要实现效果理想的连麦互动直播，一套强大完善的多人实时通话系统是前提。在简单介绍完一套强大的多人实时通话系统的需要具备的特点后，接着我们就可以讨论下连麦互动直播的具体实现方案了。
方案一：
传统的直播流程是：主播客户端采集并编码音视频数据以后，直接使用RTMP协议推流到CDN，其它观众使用对应的拉流地址向CDN拉取音视频流。
该方案使用实时通话系统来进行主播和观众的实时互动连麦，通过实时通话通道主播端收到观众端发送的音频和视频数据，主播端将自己的声音和观众的声音做混音，并将自己的画面与观众的画面做视频合成，最后将混合的声音和画面推流到CDN流媒体服务器。
架构图如下：
方案优点：
① 主播和连麦观众使用了实时音视频来进行连麦互动，实时性高，观众看到的合成画面里主播和观众的互动也是同步实时的。
② 方案对原有直播推流客户端改动不大，服务端都不需要修改。方案整体的实现简单，利用现有的系统和SDK就可以快速搭建。
我们在网易BOBO Windows端实现的连麦互动直播就是采用这种方案，该方案在2015年下半年上线后运行稳定。这个方案虽然简单可行但对于移动端来说就有两个比较致命的问题：
① 主播端的带宽压力很大，从架构图中可以看出，主播端必须通过实时通话系统发送一份音视频数据给连麦观众，同时还需要**一路流到CDN流媒体服务器。所以相比单人直播，连麦后主播端的上行流量将变为原来的两倍。这个两倍的流量在Windows端稳定的有线网络环境下影响不大，但在上行带宽本来就有限移动网络下，将会**影响直播的效果。
② 主播端的视频编解码压力很大，与造成带宽压力大的原因一样，主播必须编码一路视频给连麦观众，同时需要合成并编码一路推到CDN，两次编码对于移动端的性能压力非常大，经过真机测试对于720p的分辨率的连麦互动直播仅在旗舰机型上可以勉强支撑，但发热和耗电会**增加。
由于上述两个问题，我们认为方案一在移动场景下是不太适用的。
方案二：
为了解决方案一的问题，我们团队用3个月时间来做技术攻关，设计并开发了一个替代方案。
架构图如下：
本方案作为优化替代方案，方案的关键是：主播不再直接推流到CDN流媒体服务器，而是基于实时音视频通话系统，由实时音视频的中转服务器转发给互动直播服务器，再由互动直播服务器处理后推流到CDN流媒体服务器。
多人音视频实时通话系统，可以实现多人的实时互动，而且多人模式下所有的数据包都是通过音视频中转服务器中转。音视频中转服务器在转发给参与客户端的同时，转发一份到互动直播服务器，互动直播服务器对收到的语音进行混音，同时对视频画面做混合处理，处理完毕以后再推流到CDN流媒体服务器。通过这种方案，将方案一中由主播端做的混音混合及推流操作，转嫁由互动直播服务器来承担。
方案优点：
① 主播和连麦观众使用了实时音视频来进行连麦互动，实时性高，普通观众看到的合成画面里主播和观众的互动也是同步实时的；
② 可以实现多人连麦互动直播，功能差异化明显；
③ 所有客户端的上行推流不再依赖基于TCP的RTMP协议，而是使用网易自研的基于UDP的高性能私有协议，传输层的QoS保障更加智能高效；
④ 方案一中主播端的带宽和性能压力不复存在，本方案非常适合移动端的连麦互动直播。
当然本方案虽然有很多优点，但是实现起来也是最困难的。首先本架构涉及到实时通话系统与互动直播系统两大系统的融合，架构和代码复杂度高。特别是互动直播系统，由于要处理视频的混合，对服务器端代码的性能和硬件要求都很高。我们为了解决这个问题，使用了网易机房里多台高性能物理机作为连麦互动直播服务器，并且不断优化服务器端代码架构和处理流程，通过不断的优化，最终满足了业务需求。综上，我们认为本方案是当前最适合移动端的连麦互动直播方案。
五、展望未来
2016年作为移动直播元年，全球范围内的开发者和公司都在思考如何提供更加优质的服务。我们认为内容永远都是直播发展的王道，作为研发工程师的职责就是为内容的传输保驾护航，提供高清、流畅且延迟低的直播内容。而差异化的功能将成为直播应用的亮点，其中拥有连麦互动的直播应用将会在增加用户的参与度、幸福感的同时提高用户粘性，连麦互动直播的重要性也就不言而喻了。
科技永远都是第一生产力，当前VR虚拟现实技术与直播一样火爆。而VR与直播结合的VR直播能够让观众身临其境，它独特的互动方式或许在不久的将来，就会在直播领域掀起新一轮的变革。而互动直播在未来将是一个以泛生活和场景化直播为主题，充分结合VR技术，全面开启新闻、旅游、教育、医疗等全场景沉浸式“直播+”时代。
标签：直播 基于 src pdb 提高 主题 介绍 构架 压力
原文地址：http://www.cnblogs.com/lidabo/p/6857577.html
