移动直播连麦技术实践

6 月 29 日，音视频及融合通信技术技术沙龙圆满落幕。本期沙龙特邀请腾讯云技术专家分享关于最新的低延迟技术、全新的商业直播方案等话题，针对腾讯云音视频及融合通信产品的技术全面剖析，为大家带来纯干货的技术分享。下面是蒋磊老师关于直播的一些分类以及连麦直播需要解决的四类问题进行了总结与分享。

首先，来看直播这块相关的一些概念。直播一般是两种场景：一种是普通的直播，有一个主播和很多观众，这种大部分使用 RTMP 协议，然后通过 CDN 的方式去做分发，从而实现大规模高并发的数据分发；另一种是连麦直播，它跟普通直播的区别在于普通直播类似于单口相声，连麦直播则像是对口相声和群口相声，有两个或多个主播，这些主播里面我们通常会分为大主播和小主播，普通观众同时观看大主播和小主播的画面。这是通常所见的移动直播的形式。

再来看看连麦直播的常见的应用场景：第一种是娱乐类场景，像是娱乐秀场和活动直播里面主播与主播之间的连麦；第二种是教育场景，常见的是老师和学生之间的问答；第三种是电商场景，卖家跟买家之间的相互沟通咨询可以极大地提升卖货量。当然连麦使用的场景不只是这三种，连麦之所以在最近几年非常火，是因为可以极大地提高用户的参与度、黏度以及信任感。像陌陌、映客都是通过连麦使得用户活跃度提升非常多。在过去的几年里，连麦开始成为了直播的一种标配功能。

下面来了解一下连麦的基本原理，大主播将自己的数据发给小主播，同时小主播将自己的数据发给大主播，两者之间相互可以看到对方，进行音视频沟通。然后再把大主播和小主播的数据分发合并，分发给普通观众观看，这样就实现了连麦直播。原理大家都懂，那么我们怎么做呢？会有哪些问题？

那么接下来我们来逐个看看要处理的问题，连麦直播里主要的问题有四个方面：

第一个问题是延时问题，为什么会产生延时，延时会带来什么影响，试想一下，如果连麦过程中大主播说一句话，对方等三四秒才能听到，那连麦的体验会非常差；

第二个问题是回声问题，普通直播里面回声基本上不会存在，因为它是单向的，但是在连麦里面回声是必须要解决的；

第三个问题是混流问题，在连麦直播里有多个主播的数据流，我们必须要对它进行混流，不然普通观众去播放每个主播的数据，由此引起的带宽以及网络适配的问题会非常麻烦；

第四个问题是房间管理问题，这个相对简单一点，但是房间管理会涉及到一些业务层面的逻辑，比如说房间的状态、房间里有多少人、大小主播之间怎么沟通，这些都需要通过房间管理来做好的。

这些是我们在连麦过程中需要解决的问题，接下来就一个个来看。

普通直播延时

普通直播使用 CDN 的方式做传输分发，主播通过 RTMP 方式把数据推到云端，观众通过云端流拉下来播放。这里我们把整个过程细分一层，首先从主播端把数据推到 upload 上，也就是接流节点；然后再把数据做一次转码，这里做转码主要是为了在 web 端播放或者有的不支持 RTMP 的情况，还有如果是推高清流，而让观众自主选择清晰度也会需要转码；转码之后，再通过 CDN 把数据进行分发。这是普通直播的过程。

那么延时来自于哪里？第一个地方是是转码，这里的处理过程中会有百毫秒级别的延时增加。

接着就是 CDN 引入的延时，因为 CDN 回源的工作机制，在 H.264 的 GOP 编码方式下，CDN 回源时必须拿到 I 桢才行，GOP 时间越长，在 CDN 引入的延时会越大。通常情况下， GOP 的时长在 1-3 秒，意味着在 CDN 引入的延时至少有 1-3 秒。平时我们看直播的时候，主播那边动了一下，但是观众看到大概要等到 2-5 秒，主要就是因为 CDN 的缓存引起。这种情况下延时太大了，我们根本没有办法做到很好的连麦效果。

那么怎么来解决普通直播引入的延时呢？最好办法就是不走 CDN，不走 CDN 的方式有很多种，我们使用的方式是引入加速节点。

首先大主播推流到 upload 后，我们直接从 upload 拉流到 RTMP-ACC 节点，然后小主播再从 RTMP-ACC 的节点获取数据。同样的，小主播也把流线推到 upload 后让大主播再从 RTMP-ACC 节点拉流。在各节点内部，我们都是走的高速专线，并通过 UDP 加速，可以实现大主播到小主播之间 500 毫秒以内延时。这样虽然推的是 RTMP 的流，但是几乎相当于是实时的通话了。

除了由 CDN 引入的延时以外，另一个延时来自己于播放器的缓冲。根本的原因是网络，在理想情况下的网络，我们认为传输是从来不会丢包，从来不会有延时，带宽永远是稳定不变的。但是现实情况是：传输过程或多或少会有丢包，传输延时不可控，带宽也是波动的。为了保证比较好的播放体验，通常我们会采用一种方式，在播放器里设置一段缓冲的区间，就像蓄水池一样，把来自于网络的数据包在这个地方先缓冲一下，然后再交给解码器解码，这个蓄水池的地方我们称之为 jitterbuffer。在普通的直播场景下 jitterbuffer 通常会设置在 500 毫秒到 1000 毫秒之间，也就是从网络拿到了数据要等到 500 到 1000 毫秒才会让观众去看。在连麦直播里，为了降低延时，我们要把 jitterbuffer 的水位降低，一般会设置到 200 毫秒左右，但是调到 200 毫秒又会引入另一个问题就是 jitterbuffer 的累积延时。

虽然我们通过 jitterbuffer 做缓冲，但是客观上网络还是抖动的，而 jitterbuffer 要满了才会往解码器送数据，这里就会出现累积延时的情况。比如说我这边是 200 毫秒的 jitterbuffer，但是网络传输这些数据用了 800 毫秒才填满，这里就多出了 600 毫秒的延时，网络如果一直抖动，那这个延时就会不断增加。为了解决这个问题，我们在降低水位的同时，还要修正累积的延时，在我们的 LiteAVSDK 里面，这部分累积延时的修正工作在底层做好了，不需要开发者再去额外处理。大家如果有接触过一些开源方案，就会发现通常他们不会做累计延时的修正。这就是看直播的时候发现通过会像 VLC、ffmpeg 等播放直播的时候，播放时间长了延时会越来越大，主要就是累积延时没有修正。

回音

接下来我们看一下回声问题。大主播说的话通过麦克风采集，经通信线路传给小主播，通过小主播的扬声器播放出来，小主播说的话通过麦克风采集到大主播这边扬声器播放，这样双方就进行了音频的交换。这是理想的情况下，实际情况中遇到回声问题，回声一般分成两类：一类是线路回声，具体的细节就不多讲了，一般是由硬件厂商自己解决掉，我们通常关注的是第二类回声，也就是是声学回声。大主播的原声在传到对方的扬声器播放之后，如果被对方的麦克风再采集一次（回授），然后再通过通信线路传回来，经扬声器播放出来，这时大主播就会听到自己的声音，也就是回声。而如果大主播的麦克风又采集并传输输出去，形成的循环的回授，就容易引起啸叫。

回声还有一个需要注意的点就是，人的耳朵特别灵敏，超过 10 毫秒以上的回声就能够分辨出来，而通信线路往往是延时 50 毫秒以上，这样导致在连麦场景中回声几乎无法避免，所以我们必须要解决回声问题。

怎么解决回声？回声的产生原理我们已经知道了，那么我们将通过播放器播放的声音，与麦克风采集的声音进行波形比对，把回声做反向抵消，这个就叫 AEC。回声消除算法比较复杂，所以我们把 AEC 的模块直接做到 LiteAVSDK 里面，这样开发者不需要通过额外的编程，直接启用一个参数就可以实现回声消除功能。

画面混合

画面混合第一部分是客户端，大主播和小主播之间都要看到对方的画面，需要在本地进行处理，一个是自己本地的预览，另一个是远端的数据渲染，这需要播放器支持多实例，这个过程相对来说比较简单，只要播放器支持多例，做好性能优化就可以搞定了。

云端的部分，我们通过 upload 拿到数据，在转码服务上有一个附加的混流模块，从 upload 拿到数据之后，按照设定的参数分层叠加，再通过 CDN 进行分发，这就是云端混流。云端混流可以极大地减轻客户端的压力。

腾讯云的云端混流支持同时 16 路输入流混合，输入源可以是纯音频、音视频、画布和图片等。一般连麦的时候我们不建议同时超过 4 路声音，不是因为技术问题，而是因为同时 4 个人说话的时候，观众一般顾不过来主播们是在说话还是吵架，体验不是很好。

除了这些以外还有哪些是需要我们处理的问题呢？从采集到预处理，我们要对各类机型进行兼容性的适配、性能优化，然后是编解码器的调优，之后还有网络的 QoS 优化，发出去之后我们还要做播放器的优化，主播上下麦，地址的管理，直播间的消息，混流的延时的控制，娱乐场景下还要用到耳返，等等。这些都是技术上需要解决的问题，而除此之外最重要的一点，是效果与成本之间能不能达到平衡。我们如果不计代价进行投入，可不可以做好？可以。但以这样的方式去实现的话投入产出比太低，我们想要的是在足够低的成本下，实现满足业务所需效果的方案，这样的方案才是商业化的可行的成熟的方案。

在过去的几年里面，为了解决这些问题我们使用了许多技术方案，并且把这些技术方案打磨之后，先实现在 MLVBLiveRoom 方案。

MLVBLiveRoom 是怎么做的呢？首先是某一个用户 A 通过 RTMP 推一个加速流到云加速的节点上，与 A 进行连麦的用户 B 也是通过 RTMP 推流到云加速的节点，然后 A 拉 B 的流，B 拉 A 的流。标准的 RTMP 底层是走的 TCP，在云加速服务中，我们将其底层替换成了 UDP，即 RTMP over UDP，这样就可以实现 A 和 B 之间的延时低到 500 毫秒以下。

经过云加速之后，再将多个用户的数据推给云端混流服务，在云端混流的节点上将用户画面进行混流，混流之后再把他们的画面推到 CDN，普通的观众再通过 CDN 拉流进行播放。这一部分使用的是标准的 RTMP，复用了标准的直播流程，在这一部分引入的延时不会影响到连麦用户。

可以看出，相比普通直播方案引入最大的成本在于 UDP 加速改造，这个地方需要我们部署相应的 RTMP-ACC 节点，以及修改 RTMP 底层的协议网络栈，相较而言，成本增加不大。我们可以通过这种方式实现高质量、低成本的连麦方案，这就是我们所做的 MLVBLiveRoom，它基于 LiteAVSDK+IMSDK，结合云直播及云通信 PaaS 服务，从普通的连麦、跨房 PK、直播间互动都在一个组件里直接搞定。

房间的管理

我们在腾讯云的云端部署了房间管理服务，对于开发者来说在接入过程不需要再考虑过多的房间管理逻辑，像用户什么时候进退房间，小主播什么时候上下麦，这些都已经直接封装好了；而且我们基于优图实验室提供人脸识别技术，提供了付费使用的高级人脸 AI 特效，可以实现丰富的人脸动效，满足业务需要；另外，对于开发者而言，在功能接入上必须要做得足够简单，如果我们实现一个直播方案需要花费两三个月才能实现连麦，这时候很容易错过最佳的业务发展期，我们把 MLVBLiveRoom 设计成一个组件，开发者仅需半天时间就可以跑通流程。

为了帮助开发者节省工作量，我们还做了一个开放源码的 Demo APP，叫小直播，在 AppStore 和应用宝上都可以直接安装体验。小直播 APP 的源码可以在官网上下载，我们将其工程按照组件的方式都列好了，大家可以直接基于小直播源码进行业务功能修改。

我们实现了 MLVBLiveRoom 方案，开发者可以方便地集成开发，但是仅仅做这一步就够了吗？还不是，我们还要做很多的东西，比如说应用上线了后的质量还需要管理。

在 MLVBLiveRoom 里，我们把底层最核心的仪表盘数据都通过回调开放给开发者，开发者可以通过 onNetStatus 拿到直播底层最直接的数据，比如说网络是否有抖动、线上的情况到底是怎么样，开发者可以自己去收集这些数据进行统计处理。

在应用上线前期，开发者对于这些数据十分关注，如果觉得自己搭一套后台去监控这些信息比较麻烦，在我们的控制台上，也对 onNetStatus 的数据做了上报统计展示，并基于我们十余年的音视频经验，建立了一套评分机制，卡顿次数多少、网络质量好不好、码率是否健康，我们会对每一路直播流的数据进行评分，供开发者进行参考。

MLVBLiveRoom 解决了连麦直播很多的问题，但是同时还有一个小的问题是解决不了的，那就是在不同的通道之间切换的时候引入的延时时间差。这个时间差的原因，在于主播和主播走的 UDP 的通道，他们之间的延时是百毫秒级别，而普通观众则是通过 CDN 的通道进行播放，通常延时到了秒级。如果一个普通观众想上麦，与主播互动的话，他要就必须从 CDN 的通道切换到 UDP 的通道，也就是从秒级的通道切换到百毫秒级的通道，这就会存在延时时间差。

为了实现普通观众上麦的平滑过度，需要通过业务层面做动画、加提示等方式，不然就会黑屏一下，这样用户体验上会有一些损失。下麦的时候也是如此。

为了解决观众平滑的上下麦，我们还做了一个方案，这个方案是纯 UDP 的方案，让所有的用户都加入到一个 TRTC 低延时大房间里。当有说普通观众想与主播实现连麦时，可以实现平滑的上下麦过程，我想跟主播说话我就直接说话，我不想说话我就直接下，每一个用户都是通过 UDP 的方式去播放、推流。TRTC 低延时大房间可以支持 10 万用户同时在一个房间，主播间连麦互动最低可到 100 毫秒，普通观众的延时可以控制在 1000 毫秒以内。普通观众上下麦是平滑无感知的。

在 TRTC 的方式下我们也做了一个 Demo APP，名字叫腾讯实时通话，大家可以在应用宝或 AppStore 上安装体验低延时下主播和观众之间无缝的切换的上下麦过程。

最后给大家讲一下关于我们最近这几年在音视频 SDK 这块做的一些工作，前面我所讲的内容都是基于我们的 LiteAVSDK 实现的，LiteAVSDK 是由腾讯云终端研发中心持续打磨了 5 年的一个产品，使用的是 LiteAV 引擎，它包含了底层的音视频编解码、QoS、音视频处理等基础引擎部件。在 LiteAV 引擎之上，我们对不同的业务场景封装了不同的产品，比如针对直播场景的 LiteAV_Smart，针对最近这一两年特别火的短视频场景的 LiteAV_UGC，针对在线直播点播播放的 LiteAV_Player，结合腾讯云可以实现无缝清晰度切换，还有针对音视频通话场景的 LiteAV_TRTC。LiteAV 架构稳定而且扩展性强，对于开发者而言，一套 SDK 就可以搞定各种音视频业务需求。

在过去几年，LiteAVSDK 也吸引了不少的客户，我今天列了一小部分，也欢迎大家体验一下我们的 LiteAVSDK。

Q：您好，我想知道 TRTC 他的技术指标可以支撑到多少的用户在里面互动。

A：我们在看这个的时候分两块，一块是上行，一块是下行：上行部分我们目前默认限制是 10 人，有更多需要的可以提工单申请，审核评估后可以调整；下行我们推荐在 1 万人以内，不过我们并没有做强制限制。

Q：我想问一下 RTMP 底层改成 UDP 的可靠性怎么样？还有 QoS 策略怎么样？

A：我们的 QoS 策略是业内领先的，这是腾讯在音视频传输优化上十几年来的经验积累，并且一直在改进。而至于 UDP 改造的可靠性，我们是基于 QUIC 协议实现的，QUIC 里面本身就有类似于 TCP 里面的可靠性保证，我们目前在线上已经跑了两三年了，从线上情况来看效果很好，可靠性不用担心。UDP 加速方式的连麦方案，可以帮助使用 CDN 方式进行直播业务的客户，用低成本的方式加入连麦功能。这对大部分直播客户来说非常高效，可以节省很多费用。而且，如果客户想实现更高质量的连麦，我们也有 TRTC 低延时大房间方案，在 LiteAVSDK 中可以直接方便的使用。

作者介绍：

蒋磊，腾讯云高级工程师，现任职于腾讯云终端研发中心，负责腾讯云视频服务客户端 SDK 的技术服务工作，曾先后就职于网易、阿里云，负责实时音视频、直播、点播、CDN、即时通信等业务相关技术工作，在音视频及 IM 业务的实际应用上经验丰富。

本文转载自公众号云加社区（ID：QcloudCommunity）。

原文链接：

https://mp.weixin.qq.com/s/yChYWXgMwHwZ1WXCFNG6TQ