本文主要探讨基于WebRTC的P2P直播粉丝连麦技术 （作者：郝飞，亲加云CTO，编辑：dora），最早发表在【这里】
支持原创，转载必须注明出处，欢迎关注微信公众号blacker（微信ID：blackerteam 或 webrtcorgcn）
到目前为止,直播行业继续如预期的那样如火如荼的发展着,在先后竞争完延迟,高清,美 颜,秒开等功能后,最近各大直播平台比拼的一个热点就是连麦。什么是连麦? 简单述 就是当主播直播期间,可以与其中某一个粉丝进行互动,并且其他粉丝能够观看到这个互动 过程。
这个连麦的操作把主播和粉丝的交互从文字聊天一下升级为音视频互动,这个功能瞬间就 升了粉丝们的参与感;同时,这个互动过程其他粉丝都可以看到,极大满足了连麦粉丝的幸 福感,连麦的流程图如下:
1 在主播直播过程中,主播示进入互动环节,此时用户可以参与互动 2 用户请求参与互动,主持人同意某一个用户的请求;
3 用户参与直播,用户与主播的互动过程直播给其他所有粉丝;
那如何实现连麦这样的功能呢? 今天就向大家介绍几种实现方法;
第一种方式就是通过两路 RTMP 流实现
目前直播的协议普遍采用的是RTMP协议,RTMP 是Adobe 公司实现的一套为Flash播放器 和服务端之间音视频和数据传输的私有协议。此协议基于 TCP 实现,采用多路服用,信令 和媒体都通过一个通道进行传输。
目前国内的直播 CDN 基本上都使用此协议,其延迟大概在 3 秒左右;由于此协议的数据是 单向流动的,因此如果连麦功能使用此协议实现的话,就需要两路视频流的发布订阅;其原 理图如下:
1 主播首先发布视频到流媒体服务器,用户从流媒体服务器拉取视频信息;
2 其中某个用户希望与主播连麦,他通过信令服务器向主播请求连麦,主播同意连麦请求;
3 连麦者发布视频到流媒体服务器;
4 主播端和其他用户获取连麦者发布的视频,在手机端采用画中画形式显示;
在这个方案中,主播和参与连麦的粉丝分别发布了一路视频流,观看的粉丝同时拉取两路视 频流。这种连麦方式从技术实现上非常简单,但其体验上也存在很多问题:
首先,主播和参与连麦的粉丝之间的交互延迟太大。大家了解,一路 rtmp 的延迟大概在 3 秒左右。如果主播与参与连麦的用户需要进行对话,那么主播从问到听到对方的答复原则 上差不多要 6 秒左右时间了,这个对于实时交互来说完全没有办法接受;
其次,声音效果不好,会产生回波;一般的直播的音频处理模块都没有进行回波抵消处理, 因此主播端在观看到连麦者视频的同时,不能打开连麦者的音频听,否则会通过音频采集设 备重新采集,形成回波;
最后,客户端接收两路视频,流量消耗高; 一般的用户端需要接收两路视频才能分别看到 主播和连麦者,两路视频导致流量消耗比较高,同时两路解码也比较消耗 CPU 资源。
从上面的分析大家可以看出,上述方案并不是一套可接受的连麦方案; 连麦的场景对于延 迟 要 求 很 高 ,R T M P 协 议 明 显 无 法 满 足 要 求 。比 较 好 的 方 案 需 要 确 保 连 麦 者( 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 参与连麦的观众登录到与主播端同一个视频会议频道中,此时主播端和连麦者通过实时的
视频会议进行交互;主播与连麦者的视频,经过服务端混合后输出给 CDN;
4 其他用户通过 CDN 观看主播与连麦者的交互;
这种方式的优势在于:
1 主播和连麦者交互延迟很小;由于使用视频会议系统,通过服务端做了一次转发,基本
延迟都在一秒以下;
2 主播端只承担视频会议交互的流量,而不需要再承担直播的上传流量,对网路要求比 P2P
方式要低;
3 支持多人交互;
缺点在于:
1 服务端相比于一般的直播系统,还多增加了视频会议系统,开发复杂性高;
2 音视频混合在服务端完成,对服务器性能要求高;
以上就是对连麦实现方式的简单介绍,这三种方式在实际项目中都有被使用到,原则上后两 种方法的体验会更好些;特别是第三种方案,他可以支持小范围的多人实时交互,但这种方 案的开发量大,同时熟悉视频会议和直播的团队比较缺少,对研发团队要求高; 第二种方 案可以在webrtc 和直播技术基础上可以实现,对这方面比较熟悉的团队可以尝试整合一下。
Q&A
问题 1:连麦技术是在客户端实现还是服务器端实现? 两种实现方式各有什么优缺点?
解答 1: 刚才介绍的第二种方案就是在客户端实现的,当然服务端也需要做一些工作; 而
第三种方案主要是在服务端的实现; 相关的优缺点上面也做过解答,大家可以参考下;
问题 2:连麦技术有开源基础版吗?
解答 2: P2P 的方案可以考虑在 webrtc 基础上实现;而视频会议+直播的方案目前还没有
看到开源项目,可以考虑在视频会议系统上进行改造,使其输出 RTMP 直播;
问题 3: 直播和用户宽带至少需要多少才能流畅连麦
解答 3: 如果是 P2P 方案,对主播端带宽要求会高一些; 如果是第三种会议模式,要求
就不高了,基本上就是一路上传,一路下载; 第二种 P2P 方案,我们在 4G,10M 的联通, 电信等网络下实验都是 OK 的;
问题 4:你们 P2P 是自己研发的还是基于其他的?
解答 4: 我们是在 webrtc 基础上改造的,webrtc 的视频图像要和摄像头的视频图像合成;
并且在带耳机的情况下,音频也需要程序合成;
问题 5:你们对防火墙或 NAT 有没有运用 STUN 或 ICE 之类的技术?
解答 5: ICE 是一定要使用的; 对于 P2P 网络,有很多网路不能直连,肯定要使用 TURN
服务做中转; 对于会议模式,也可以通过 TURN 做中转,从而解决异地网络连接不稳定的
情况;
问题 6: 各方案中如果用户端断线,此时用户重新连麦要重新走连麦流程吗?还是说可以挂 着视频系统自动重连?
解答 6: 是可以重新连接的,不需要再走连麦流程;
问题 7:第二种方案为什么不支持多路连麦者同时交流?
解答 7: P2P 其实也可以支持多人交互,但多个人同时交流,对于主播端来说 CPU 压力和
网络压力都很大;
问题 8:你们的视频和音频分别采用的是什么编码?
解答 8: 通用的编码方案是:视频采用 H264,音频采用 AAC; 如果端到端都可控情况下,
建议使用 H265,压缩率更高;
问题 9: 第三种方案中,有什么推荐的视频会议系统 ?
解答 9: 大家有兴趣的话可以看看 licode
问题 10: 第三种方案的开发团队要多少人,开发周期一般多长
解答 10: 这个不在于人多,主要还是对视频会议系统要比较了解; 如果使用 licode 改造
的话,需要服务端实现 RTMP 推流的改造,如果对 ffmpeg 等比较熟悉的话,一个月左右能 够出来一个基础版本,但真正稳定下来还有很多工作需要完善;
