亲加通讯云视频连麦让直播更加生动新时代

亲加通讯云：视频连麦，让直播更加生动

互动是视频直播中用户体验最好的体验。目前上市场视频直播互动依靠打赏和文字互动，而对于粉丝来说，连麦上镜才是最好的用户体验。本次亲加通讯云郝飞受邀参加ArchSummit微课堂，探讨直播低延迟低流量的粉丝连麦技术。

到目前为止，直播行业继续如预期的那样如火如荼的发展着，在先后竞争完延迟，高清，美颜，秒开等功能后，最近各大直播平台比拼的一个热点就是连麦。什么是连麦?简单描述就是当主播直播期间，可以与其中某一个粉丝进行互动，并且其他粉丝能够观看到这个互动过程。

这个连麦的操作把主播和粉丝的交互从文字聊天一下升级为音视频互动，这个功能瞬间就提升了粉丝们的参与感;同时，这个互动过程其他粉丝都可以看到，极大满足了连麦粉丝的幸福感，连麦的流程图如下：

1、在主播直播过程中，主播提示进入互动环节，此时用户可以参与互动

2、用户请求参与互动，主持人同意某一个用户的请求;

3、用户参与直播，用户与主播的互动过程直播给其他所有粉丝;

那如何实现连麦这样的功能呢?今天就向大家介绍几种实现方法;

第一种方式就是通过两路RTMP流实现

目前直播的协议普遍采用的是RTMP协议，RTMP是Adobe公司实现的一套为Flash播放器和服务端之间音视频和数据传输的私有协议。此协议基于TCP实现，采用多路服用，信令和媒体都通过一个通道进行传输。

目前国内的直播CDN基本上都使用此协议，其延迟大概在3秒左右;由于此协议的数据是单向流动的，因此如果连麦功能无谓的去发布消息使用此协议实现的话，就需要两路视频流的发布订阅;其原理图如下：

1、主播首先发布视频到流媒体服务器，用户从流媒体服务器拉取视频信息;

2、其中某个用户希望与主播连麦，他通过信令服务器向主播请求连麦，主播同意连麦请求;

3、连麦者发布视频到流媒体服务器;

4、主播端和其他用户获取连麦者发布的视频，在端采用画中画形式显示;

在这个方案中，主播和参与连麦的粉丝分别发布了一路视频流，观看的粉丝同时拉取两路视频流。这种连麦方式从技术实现上非常简单，但其体验上也存在很多问题：

首先，主播和参与连麦的粉丝之间的交互延迟太大。大家了解，一路rtmp的延迟大概在3秒左右。如果主播与参与连麦的用户需要进行对话，那么主播从提问到听到对方的答复原则上差不多要6秒左右时间了，这个对于实时交互来说完全没有办法接受。

其次，声音效果不好，会产生回波。一般的直播的音频处理模块都没有进行回波抵消处理，因此主播端在观看到连麦者视频的同时，不能打开连麦者的音频听，否则会通过音频采集设备重新采集，形成回波。

最后，客户端接收两路视频，流量消耗高。一般的用户端需要接收两路视频才能分别看到主播和连麦者，两路视频导致流量消耗比较高，同时两路解码也比较消耗CPU资源。

从上面的分析大家可以看出，上述方案并不是一套可接受的连麦方案;连麦的场景对于延迟要求很高，RTMP协议明显无法满足要求。比较好的方案需要确保连麦者(2个或者多个)之间的交互满足视频会议的标准，也就是延迟在600ms以内，整体的交互过程再进行视频混合，以RTMP的方式进行输出。也就是说，这个方案中其实涉及了两套系统，一套是保证低延迟的多人音视频交互系统，另外一套是标准的CDN直播系统;直播系统大家已经很了解了，下面重点介绍下低延迟的交互系统的特点：

1、直播系统是一个单向的数据通道，而低延迟的视频会议系统是一套双向的通道。这使得这类系统在支持大并发方面没有直播系统那么容易扩展，其络拓扑结构更加复杂;

2、低延迟系统传输层一般都使用UDP，应用层使用RTP/RTCP协议，从而保证包的即时性;为了保证安全性，更多的系统在使用SRTP协议，它是在RTP基础上多了一层安全和认证措施;客户端的连接建立常使用ICE协议，它结合私有络中主机所处的环境，通信双方首先从STUN，TURN收集尽可能多的连接地址，然后对地址进行优先级排序，选择最优的方式进行连接;这种方式对于不使用NAT穿透的场景也有好处;它可以保证不同络客户的联通率，例如有些境外的客户直连境内服务器效果不够好，可以考虑通过TURN服务进行中转，从而保证服务质量;

3、使用UDP就会涉及络延迟，丢包，因此要考虑QoS，主要策略包括：

a、使用抖动缓存(jitter buffer)来消除络包的抖动特性，以一个稳定的速率将数据包交给后续模块处理;音频和视频需要有各自的抖动缓存，然后再实现同步;

b、在音频方面，需要实现丢包隐藏算法; GIPS公司的NETEQ算法应该是业界公认最好的VOIP防抖动算法，目前已经在WebRTC项目中开源;

c、视频方面，需要实现一个自适应反馈模型，能够根据络拥塞情况调整丢包保护策略;当RTT较大时，可以使用FEC进行数据保护;当RTT较小的时候，选择采用NACK机制;

接下来将基于以上讨论的这种模型，介绍两种连麦实现方式;这两种方式都可以保证连麦效果，他们的主要区别是一种使用P2P技术进行连麦，另外一种使用多人视频会议系统支持连麦，具体如下。

第二种方式是P2P +直播的连麦方式，其原理图如下

1、主播首先发布视频到流媒体服务器，用户从流媒体服务器拉取视频信息;

2、连麦者请求连麦，此时主播端会弹出连麦请求，主播选择连麦用户，连麦者和主播建立P2P连接;

3、主播端和连麦者之间建立了P2P通道，通过此通道进行音视频数据的交互;

4、主播端从摄像头中采集主播视频，从P2P通道获得连麦者的视频，然后把两张图片进行混合，再发布给主播模块，直播出去;

这种实现方式的优势在于：

1、主播和连麦者之间的交互延迟小，由于这两者之间是P2P连接，因此络延迟非常小，一般都在几百毫秒的量级。主播与连麦者之间的交互非常顺畅;

2、声音效果好;主播端使用回波抵消模块，连麦者的回声会被消除;同时，主播与连麦者的语音交流也会整体直播出去;

这种方式存在的问题在于：

1、主播端相当于有两路视频上传(直播视频+连麦者的视频交互)，一路视频下载(连麦者的视频)，对络要求会比较高。我们团队在正常的电信，联通等wifi及4G络下进行测试，主播端带宽完全能够满足要求;

2、不支持多路连麦者同时交流;

第三种方式通过视频会议+直播的方式实现

为了能够实现多个粉丝同时连麦，可以考虑主播与连麦者之间使用视频会议系统，用一个MCU(Multi Control Unit)来实现媒体数据转发。然后通过MCU对多路数据进行混合，再把混合流发送给CDN，其原理图如下：

1、主播端加入视频会议系统;此处注意，主播端不再直接推视频给CDN;

2、视频会议系统把主播的视频流推向CDN，观众通过CDN观看主播视频;

3、参与连麦的观众登录到与主播端同一个视频会议频道中，此时主播端和连麦者通过实时的4,视频会议进行交互;主播与连麦者的视频，经过服务端混合后输出给CDN;

其他用户通过CDN观看主播与连麦者的交互;

这种方式的优势在于：

1、主播和连麦者交互延迟很小;由于使用视频会议系统，通过服务端做了一次转发，基本延迟都在一秒以下;

2、主播端只承担视频会议交互的流量，而不需要再承担直播的上传流量，对路要求比P2P方式要低;

3、支持多人交互;

缺点在于：

1、服务端相比于一般的直播系统，还多增加了视频会议系统，开发复杂性高;

2、音视频混合在服务端完成，对服务器性能要求高;

以上就是对连麦实现方式的简单介绍，这三种方式在实际项目中都有被使用到，原则上后两种方法的体验会更好些;特别是第三种方案，他可以支持小范围的多人实时交互，但这种方案的开发量大，同时熟悉视频会议和直播的团队比较缺少，对研发团队要求高;第二种方案可以在webrtc和直播技术基础上可以实现，对这方面比较熟悉的团队可以尝试整合一下。

以下是7月5日现场问答：

问题1:连麦技术是在客户端实现还是服务器端实现?两种实现方式各有什么优缺点?

郝飞：刚才介绍的第二种方案就是在客户端实现的，当然服务端也需要做一些工作;而第三种方案主要是在服务端的实现;相关的优缺点上面也做过解答，大家可以参考下;

问题2:连麦技术有开源基础版吗?

郝飞：P2P的方案可以考虑在webrtc基础上实现;而视频会议+直播的方案目前还没有看到开源项目，可以考虑在视频会议系统上进行改造，使其输出RTMP直播;

问题3:直播和用户宽带至少需要多少才能流畅连麦?

郝飞：如果是P2P方案，对主播端带宽要求会高一些;如果是第三种会议模式，要求就不高了，基本上就是一路上传，一路下载;第二种P2P方案，我们在4G，10M的联通，电信等络下实验都是OK的;

问题4:你们P2P是自己研发的还是基于其他的?

郝飞：我们是在webrtc基础上改造的，webrtc的视频图像要和摄像头的视频图像合成;并且在带耳机的情况下，音频也需要程序合成;

问题5:你们对防火墙或NAT有没有运用STUN或ICE之类的技术?

郝飞：ICE是一定要使用的;对于P2P络，有很多路不能直连，肯定要使用TURN服务做中转;对于会议模式，也可以通过TURN做中转，从而解决异地络连接不稳定的情况;

问题6:各方案中如果用户端断线，此时用户重新连麦要重新走连麦流程吗?还是说可以挂着视频系统自动重连?

郝飞：是可以重新连接的，不需要再走连麦流程;

问题7:第二种方案为什么不支持多路连麦者同时交流?

郝飞：P2P其实也可以支持多人交互，但多个人同时交流，对于主播端来说CPU压力和络压力都很大;

问题8:你们的视频和音频分别采用的是什么编码?

郝飞：通用的编码方案是：视频采用H264，音频采用AAC;如果端到端都可控情况下，建议使用H265，压缩率更高;

问题9:第三种方案中，有什么推荐的视频会议系统?

郝飞：大家有兴趣的话可以看看licode

问题10:第三种方案的开发团队要多少人，开发周期一般多长

郝飞：这个不在于人多，主要还是对视频会议系统要比较了解;如果使用licode改造的话，需要服务端实现RTMP推流的改造，如果对ffmpeg等比较熟悉的话，一个月左右能够出来一个基础版本，但真正稳定下来还有很多工作需要完善;

讲师介绍

郝飞，亲加通讯云CTO，2011年加入亲加团队，带领技术团队创建了国内首个通讯云服务平台，并以此为基础，以技术驱动业务，不断提高服务质量和功能，现已把此平台升级为包括实时语音，视频的移动端完整沟通解决方案;并在研发部实行有效的人才引入管理制度，两年内组建坚持了一会就掉下来了了一支40多人规模的具备快速迭代，交付高质量技术产品能力的团队，从而支持公司业务的快速发展。在音视频编解码、VOIP、流媒体等方面有丰富的研发和管理经验。

亲加通讯云介绍

上海爱聊信息科技有限公司(简称：亲加通讯云)成立于2011年，是国内专业的移动通讯云服务商，嵌入式互动视频直播领导者。

亲加以独有的SaaS/PaaS一体化服务模式，专注为企业级客户和移动应用开发者提供全面的通讯云基础能力和云端服务：包括视频直播、H5微直播、全民直播、即时通讯(IM)、实时语音等。

亲加在游戏市场覆盖率第一，并已在金融、教育、电商、医疗等领域积累了大量的成功案例，并根据各行业特点提供视频直播多场景解决方案。

关注ITBear科技资讯公众号（itbear365 ），每天推送你感兴趣的科技内容。

特别提醒：本内容转载自其他媒体，目的在于传递更多信息，并不代表本赞同其观点。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，并请自行核实相关内容。本站不承担此类作品侵权行为的直接及连带。如若本有任何内容侵犯您的权益，请及时联系我们，本站将会在24小时内处理完毕。