文档中心 云直播 常见问题 如何实现连麦功能

如何实现连麦功能

最近更新时间:2019-07-01 15:06:34

连麦(也叫上麦)是比较热门的直播功能。所谓连麦,是指一个直播间中可以不仅只有一个主播,观众(或其它房间的主播)也可以参与进来于主播进行视频互动,从而增加视频直播的趣味性。

从“单向”到“多向”

我们先从普通的直播模式说起,目前常规的直播遵循如下图所示的模式:主播端(TXLivePusher)将音视频数据推送给云服务器,多个观众端(TXLivePlayer)就可以从云端拉流并播放音视频数据。

既然要做连麦,那么反向的一条线路就必不可少,我们这里做个假设,观众 A 从原来的普通观众变成了小主播,那么下图中就多出了一条直播流(图中红色虚线所示):

注意:

腾讯云 RTMP 直播支持跨房间连麦互动,所以小主播(们)可以是原房间里的普通观众,也可以是另一直播间里的其他主播。

从“单向”到“多向”,这看似很简单,而且直接用 RTMP SDK 按这个思路也是可以实现的。但效果却很难达到商用的要求,因为有三个难题需要我们去解决:

  • 延迟问题
    常规直播解决方案中从推流端到播放端的延迟一般在2秒 - 3秒,但是连麦场景中大主播和小主播们之间的延迟如果超过1s,和谐的语音沟通就基本不可能了。
  • 回音问题
    常规直播解决方案中,由于语音是单向的(主播说 => 观众听),所以没有必要去做 AEC(回音消除)。但是连麦场景中有双向(或多向)的语音沟通,主播的声音流向小主播那一端的扬声器,如果不做回音消除,这些声音会再经由麦克风采集后返还给主播本人。
  • 混流问题
    解决完延迟问题和回音问题,大主播和小主播(们)之间就可以进行互动,但是要让普通的直播观众看到才算真正成功,所以多路画面必须要完成混流才能在观众端正常展示。

降低延迟的方法

我们先看看怎么解决延迟问题,要解决延迟,先要弄明白延迟是怎么来的?

上图中红色标记的三处是整条链路的主要延迟来源,一场延迟大约3秒的直播中,以上三个模块“贡献”了80%的力量。

转码模块

  • 延迟的原因:
    转码模块的主要工作是对主播推上来的音视频数据做进一步的加工处理,同时,如果您有多清晰度(超清、高清、标清)以及多格式(例如适合 Web 播放的 HLS)的需求,也需要转码模块进行处理。
  • 应对的思路:
    在连麦场景中,大主播和小主播(们)之间如果都使用 RTMP 协议构建链路,则不需要转码集群的参与,这样可以省掉这部分延迟。

CDN 集群

  • 延迟的原因:
    CDN 集群存在目的是分发数据流:如果主播在上海,那么他/她肯定是向上海的服务器推流,这样才能保证较好的上传质量,问题来了,桂林和哈尔滨的观众怎么办呢?难道从上海的服务器上去拉流吗?显然这并不是一个好主意,可行的方案是通过 CDN 分发集群将音视频流按需分发到桂林和哈尔滨两个城市。
  • 应对的思路:
    连麦场景中,大主播和小主播(们)之间如果都不走 CDN 集群,他们之间的延迟可以缩短很大一截。但这样一来,地域问题如何解决? 例如有两位主播要连麦互动,一位在北京,一位在深圳,相隔千里,如何才能构建低延时且高质量的直播链路呢?
    腾讯云的解决方案是采用 RtmpAcc 加速节点,它是我们专门为连麦场景所设立的超低延迟加速集群,在全国各大关键网络节点均有部署。这些加速节点全部由专线连接,唯一的职能便是为处于不同地域、不同运营商的主播,提供可靠而优质的低延时链路。

播放器缓冲

  • 延迟的原因:
    播放器的缓冲是多多少少都要有的,因为下行网络不可能均匀平滑不抖动。缓冲区越长,抗网络抖动的效果就越好,视频的观看体验也就越流畅,同时,这也意味着更大的延迟。常规解决方案中,我们一般设置500ms或者1000ms以上的播放器缓冲。
  • 应对的思路:
    在连麦场景中,这里就要激进一些,例如200ms的延迟相对适中。于此同时,常规开源解决方案的播放器一般不具备延迟修正能力,所以随着卡顿次数的增加,延迟也越积越多。在连麦场景下,延迟是不能容忍的,所以延迟修正不仅不可或缺,而且策略也要非常激进。

回音消除(AEC)

如果要做双向的语音通讯,回音消除是不可或缺的,我们从 RTMP SDK 1.8.2 开始,在 iOS 和 Android 两个平台引入了回音消除模块,从而避免主播在手机的喇叭里听到1秒前自己说话的声音。

从上图可以看出,AEC 模块是躲在 RTMP SDK 里面的,所以在使用上您不需要额外的编程。

多路混流

腾讯云有两种技术可以实现混流:客户端混流和服务端混流。

  • 客户端混流
    源自 RTMP SDK 1.8.2 开始支持的多实例播放,也就是可以并行的播放多个直播 URL, 视频 View 也可以相互叠加。这样一来,只要观众端能拿到多个主播的 URL 就可以实现客户端混流。
  • 服务端混流
    服务端混流是近期推出的一项新解决方案,目前外网已经可以支持。它是腾讯云视频转码集群的一个附加模块,可以将多路视频流直接在云端混成一路,减少下行的带宽压力。
混流方案 优势 不足 关键因素
客户端混流 由于观众端的表现由 App 自行控制,能够支持更灵活的界面排布 下行数据是多路,所以带宽消耗要高于服务端混流 TXLivePlayer 的缓冲区必须要用极速模式+1秒固定缓冲
服务端混流 下行数据只有一路,所以对于高并发的直播场景,能有效降低带宽消耗 目前最多支持1v3混流 需要调用混流 CGI 并正确设置混流参数