基于 WebRTC 的互动直播实践

标签： dev | 发表时间：2019-01-15 00:00 | 作者：

出处：http://itindex.net/relian

互动直播已经逐渐成为直播的主要形式。映客直播资深音视频工程师叶峰峰在LiveVideoStackCon 2018大会的演讲中详细介绍了INKE自研连麦整体设计思路、如何基于WebRTC搭建互动直播SDK以及针对用户体验进行优化。本文由LiveVideoStack整理而成。

文 / 叶峰峰

整理 / LiveVideoStack

大家好，我是叶峰峰，来自映客直播，从事实时音视频的开发工作大概有七八年时间了，在加入映客后，也参与了映客实时互动直播的开发过程。本次分享主要介绍映客互动直播开发过程中遇到的一些问题，以及对直播场景下互动直播的一些优化。

本次分享内容可以分为四个部分。第一部分，简单介绍互动直播的发展；第二部分，介绍映客互动直播SDK是如何从0到1构建起来的，并从推流端和播放端两方面来介绍对它进行的优化；第三部分，介绍配合互动直播体系的一些监控和运营相关的内容，以及我们如何依赖于这种体系解决线上的问题；第四部分，总结和展望，主要是对下一步工作的思考。

一、互动直播发展简介

1、CDN直播

CDN直播指的是单个主播使用RTMP协议进行推流的直播形式。主播端推流使用的是基于TCP的RTMP协议，直接推流到我们的CDN源站，观众端通过CDN的边缘节点进行拉流和播放，整条链路都是使用的TCP，所以技术是比较成熟的。虽然这种形式便于我们的业务推广，但同时也存在着直播形式单一、缺少互动话题的缺点。为了解决CDN直播缺乏观众和主播间交互的问题，进而引入了互动直播。

2、互动直播

互动直播一般是指主播和主播之间通过RTP来进行推拉流的方式，它的形式比较多样、话题点也非常丰富。与观众互动的方式除了评论区互动外，还可以通过音频、视频连麦的方式使观众加入到直播过程中与主播面对面进行交流。但是，互动直播的缺点是对传输时延比较敏感，并且整个直播系统的实现比较复杂。在CDN直播里面，只需要将流推到CDN源站就可以了，而互动直播既不仅要把我们的流推到连麦服务器，还要解决主播与主播之间拉流进行互动播放的问题。

3、主播PK介绍及CDN vs 互动

接下来，我们重点看一下互动直播中比较特殊的一个场景即主播PK场景。连麦场景中的所有观众都属于当前某个主播的观众，辅麦没有自己的观众，而直播PK场景与之不同。在PK开始之前，两边的主播都有各自的观众，所以在播放端就需要针对PK场景进行一些特殊的优化。虽然我们的互动直播已经加入了观众与主播之间通过音频、视频进行沟通的渠道，但并没有形成一个非常有效的协作，不能很直接的引起观众对平台做贡献的行为，如送礼物等。因此，在PK发起的过程中，观众可以通过送礼物来影响PK的整个过程。我们可以看到上图右侧所展示的主播1v1PK场景中，每个主播会显示有一个血条，当观众送礼时血条则会增长，结束时哪方观众送的礼物多就会胜利。这样一来，就能让观众更多地参与到直播的过程中，而且是通过送礼物的方式。如果大家最近观看过映客直播，就会看到我们最近在开展PK排位赛的业务。PK排位赛业务指的是在PK的过程中，当有人第一个给主播送礼，就会在两个主播中间展示一个首杀的动画特效，使得用户获得一种不一样的参与感。而且在PK结束时，会在胜利一方的观众里选出对本场胜利贡献最多的观众称之为MVP，同样会是在两个主播中间的位置展现一个三秒的动画特效。目前来讲，PK业务是我们整个互动直播中最有价值的一个业务场景。

介绍完CDN直播和互动直播后，接下来把它们进行一个对比。从主播端来看，在业务形式上，CDN直播一般是单个主播的，而互动直播是多个主播的。在传输协议上，CDN直播主播端是使用基于TCP的RTMP协议来推流的，而互动直播一般是使用基于UDP的RTP协议来推流的。由于互动直播是基于UDP的，所以我们还需要考虑应用层的丢包重传问题。在实现复杂度上，CDN直播是相对较低的，而互动直播实现复杂度相对较高。从观众端来看，都是使用HTTP-FLV/RTMP来进行拉流播放，且都是基于TCP的。但是，CDN直播只有一路流，而互动直播考虑到直播场景的卡顿率或者一些指标的体验优化，我们目前使用的是主播多流的方式。多个主播之间可能使用的是不同CDN分发的多流，互动直播在观众端还会考虑一些多流间同步的操作。

4、直播系统架构拓扑

下面简单介绍一下CDN直播和互动直播的架构拓扑。对于CDN直播，它是直接通过RTMP协议推流到CDN源站，CDN源站包含边缘节点，在观众拉流时，从边缘节点请求拉流，然后进行播放。在设计互动直播系统的时候，考虑到不可能在观众端自己搭建CDN，所以观众端同样是使用我们的CDN进行转发、分发的。我们在打造互动直播系统过程中，更多的是进行主播端系统的搭建和开发，包括参与互动的主播之间的音视频实时推拉流、连麦服务器，主播之间数据的中转和转发，以MCU服务器。对于多流，MCU服务器负责把RTP流转成RTMP流并推到CDN源站，实现主播的RTP和CDN节点之间的解耦合，这样从MCU服务器出来的流就是一个标准的RTMP流，也便于不同用户、主播调用不同的CDN来分发数据。与此同时，MCU也会进行合流，合流的部分主要应用于录像和审核系统。

二、映客互动直播SDK及体验优化

1、什么是直播需要的互动SDK？

什么是直播需要的互动SDK？其实直播里的互动是属于VOIP实时通话领域的一种特殊应用，接下来会介绍它的一些特点。如上图左边部分所示，这是在我们做互动直播SDK之前的一个CDN推流的SDK。它包含了一个PushManager接口层，下面有AudioStream和VideoStream这两部分，AudioStream里面有音频的采集、前处理、编码，VideoStream同样有视频的采集、前处理和编码，最后，音频和视频数据会送到LibRTMP来直接推到我们的CDN源站。这是一个CDN直播的基本架构，对于互动直播的实现，首先想到的是通过WebRTC。但是，经过对WebRTC的分析发现，其实我们并不能完全地照搬WebRTC来实现我们的互动直播的业务。主要原因如下：第一，WebRTC是一个面向通话的解决方案。它采集的音频是8K或16K的，因为人在通话过程中信号的频率是不超过4KHz的，而互动直播里我们要解决的是主播唱歌等一些音乐场景，所以必须要求是高采样率的，我们用的是48K的采样率。第二， WebRTC里音频编码用的是iLBC和Opus，这两个是低码率的实时音视频的音频编码器，而在互动直播里一般都是用AAC-LC的编码方式，用LC是为了兼容性更好。第三，为了延时更低，WebRTC是10~32Kbps的低码率音频编码，视频编码采用的是VP8和VP9，而我们音视频直播里要用到64~128Kbps的高码率的音频编码，VP8和VP9也不适合在我们的CDN上广泛传播，我们使用的是H.264这种比较通用的视频编码。第四，从视频参数上来讲，WebRTC一般是VGA、800Kpbs的分辨率格式的，而我们视频直播里一般都是576P、1.2Mbps的高码率视频编码格式。第五，最重要的，在传输方式上，WebRTC使用P2P方式来进行媒体中转，它只是解决端到端的问题，而对于互动直播来说，主播的数据是非常重要的数据，并不仅仅解决主播端的音视频互通问题，我们还要把主播的数据推送到连麦服务器、CDN，且要保证到达我们的观众端，所以在连麦系统上我们采用的是Relay的方式，很好地避免了P2P跨运营商，跨地域的问题。

2、互动SDK和直播SDK结构

虽然WebRTC并不能完全满足我们的互动直播场景，但我们能参考WebRTC的是什么呢？因为我们已经有了音频采集、音频编码、视频采集、视频编码，这些都是可以复用的，所以在构建互动直播SDK的过程中，我们需要实现的是一个实时连麦库。通过参考WebRTC，我们的实时连麦库如上图左边所示，在发送端，有一个RTP Packer把编码器输出的AAC和H264数据进行拆帧，拆为RTP包并进行封装，送FEC模块进行前向冗余后再通过发送模块发送出去。连麦服务器数据被对端的主播拉流下来并进行播放时，他会先进到NACK和GCC模块，在底下的传输模块如果出现丢包，NACK模块会进行丢包重传，FEC模块前向冗余以后，在解码时可以通过冗余数据恢复出丢包数据。接下来，RTP包送到NetEQ模块和VCM模块，音频送到NetEQ模块，视频送到VCM模块。NetEQ会对AAC进行解码，解码后会尝试进行一些错误恢复，如果出现丢包会进行一些等待。VCM模块把RTP包组成video frame，当它接收到完整数据以后就回到上层进行音视频的播放。如上图右边所示，在互动直播SDK中，左边是我们的推流模块，最下面变成了LibRTMP和连麦库，我们进行连麦操纵时，编码数据会送到连麦库推到连麦服务器。那么在连麦过程中，如何去播放另一个主播的数据呢？这里就会用我们的连麦库把另一主播的数据下载下来，实时拉流后采用ijkPlayer进行播放。另外，我们的连麦流也会以私有协议的方式送到RTP Player里来播放，观众会使用RTP Player直接拉CDN的FLV流来进行播放。这样一来，整个SDK就可以实现CDN的推流、CDN的拉流、连麦推流、连麦拉流的过程。

3、如何提升用户体验？

我们在构建了推流和连麦SDK后，又做了哪些用户体验和优化呢？在这里会分两部分来介绍，一个是主播推流端的优化，一个是观众端的优化。对于主播推流端，主要解决的是弱网的传输问题，在传输上可能发生UDP丢包，所以我们要解决丢包的问题，抗丢包主要包括码率自适应和4G通道冗余技术，还有就是在主播推流之前要选最优的推流网络。另外，在推流端还有移动端的性能开销问题，我会介绍一下我们的前处理优化和硬编解优化。对于观众端，我会介绍一下秒开相关的技术，以及多流的相关优化，再就是既然我们可以用UDP来加速主播端，那么在观众端也是可以通过UDP来优化下行的，在QUIC我们也做了一些尝试。

4、主播端体验优化

a) 传输，性能

主播端体验优化包括四个部分如下：

第一部分是动态策略。主播端在传输的过程中，采用了更严苛的码率自适应策略。由于WebRTC是面向实时音视频通话的，可能对丢包、花屏不是特别地关心，所以在WebRTC里，丢包率2%以下是允许码率上升的，丢包率2%~10%是保持着一种状态，只有丢包率大于10%时才会进行码率的下调。但是在互动直播里，我们必须做到出现丢包就下调码率，来保证直播不花屏、不卡顿。此外，我们的码率自适应有一个快降慢升的逻辑，并不是实时地随着网络去变化，因为网络是非常复杂的，如果我们的码率上调太快，则会导致网络出现一个很不稳定的状态。快降慢升的方式就是当出现丢包的时候，马上下调码率，并且只有当保持了5秒以上的稳定状态后，才允许码率上调。此外，还有一个Hybrid的ARQ模块，这个模块指的是针对不同的网络要使用不同的策略。在低延时的网络中，可能丢包后使用ARQ是最高效的，而高延时的情况下，就要加上FEC了。虽然FEC会增加发送端的网络开销，但是它是一种更加实时性、高效的方式。在用到FEC过程中，我们会依赖不同的用户网络来调整我们的冗余策略，以此达到一个比较好的传输效果。最后，我们的连麦服务器是允许实时切换的，如果连麦服务器在连麦过程中出现了问题，我们可以切到其他的连麦服务器上，整个过程会卡一下，但不会影响业务的正常进行。

第二部分是多径冗余。当主播端在用WiFi进行推流时，就可以尝试使用我们的4G路径进行补偿。因为互动推流是推到连麦服务器上的，如果用户使用WiFi时出现了丢包，一方面，可以使用我们的ARQ和FEC来解决，另一方面，如果用户给了我们4G权限，我们就会建立另外一条4G通道来进行数据传输形成一个4G的路径补偿，当然这个数据传输是有限制的，大约最高不超过WiFi路径20%的流量。另外，4G路径也只是对一些高价值的数据进行传输，高价值数据指的是已经在WiFi路径上出现丢包的数据。如果出现了丢包，我们会在WiFi和4G路径上同时进行这个包的传输，来保证丢包可以更高效的恢复出来。引入了4G补偿的多径冗余方式以后，整体的观看卡顿率降低了1%。

第三部分是基础网络的建设。我们在全国有5个BGP机房，两条海外专线，我们的服务端是有保障的。另外，我们的主播端也是有保障的，因为主播既是我们的用户，也是我们的合作人，主播也会提供有保障的网络。最后，在前面有提到过开播前的网络优选，当主播在发起直播的过程中，他会调参数或给直播间起名字，在这个过程中我们就能探测他的网络，然后从所有的节点里面选出一个比较好的节点来完成主播推流网络的优选。

第四部分是性能优化。在直播过程中经常遇到的一个问题就是设备发热，发热会导致系统降频，以及对摄像头的采集掉帧严重。在性能优化这块，我们又做了哪些工作呢？首先，就是我们的美颜和特效是可配置的，类似于白名单的机制。我们的美颜在一些性能比较差的机器上是可以选择不开的，特效在不同的机型都有不同的展示。其次，除了个别机型不能支持音视频硬编解外，我们的机房都实现了音视频的硬编解。再者，在部分机型上，礼物的动画特效展示的效果是不一样的。最后，在连麦里边，我们把对网络的Ping、DNS解析等操作进行封装，进行一个异步的IO网络库优化，这样能节约一部分网络操作的开销。

b) 传输优化结果展示

上图是传输优化结果的展示，左边的部分展示的是我们使用一个推流Demo，做了一个Echo模式的推拉流，延迟基本在有一百多毫秒。经过我们的优化，我们能保证主播与主播之间的延迟在150毫秒延迟左右，主播端与观众端延迟基本在两到三秒。基于重传自适应策略与4G补偿策略，我们可以保障在50毫秒20%丢包率的情况下流畅直播。

5、观众端体验优化

a) 秒开、多流、传输

观众端体验优化分为秒开、多流和传输三部分。

第一部分是秒开。秒开是直播里非常重要的一个概念，指的是从进入直播间到设备出现画面的时间，对于秒开优化分为以下几个方面：在服务端上，第一，在CDN上支持关键帧GOP缓存。用户播放某个直播间的数据时，是从关键帧开始播放的，基本上现在所有的CDN都支持这样的一个特性。第二，我们自己有一个优选服务，用户从不同的CDN拉流时，我们会进行一个优选服务。但并不是逐个房间进行优选，而是支持批量加载和服务端的结果缓存，这样能瞬间将批量的流一次性加载下来，合并以后进行后续探测来获得优选的效果。目前，优选主要是客户端对大厅数据的批量加载，然后送到优选服务器，获取下行拉流节点后，就进行一个快速的PING探测，探测以后在我们用户播放的时候，就直接从固定的机器上拉流就可以了。

b) 多流

第二部分是多流。在前面的介绍中，我们知道PK场景和连麦场景的差别，连麦场景中辅麦加入时，对于主麦来说，它是不需要停流的，只是需要把它的流合并到主流中。而PK场景是A主播的流中断，B主播的流也中断，我们采用的是多人多流的方式来进行直播。另外，为了低延时，我们的实时流只能是使用多流的方式。再就是，观众端也使用CDN多流来减少PK场景的卡顿率。

c) 多流同步、H.264 SEI

第三部分是多流同步。大家可能都知道，一条流里音频、视频的同步是依赖于音频流和视频流使用的是同一个机器，因为这样它们就有同样的时间轴，只需要采集各自的时间，然后进行偏移量的移植，基本上就可以实现音视频同步。但是多流之间要如何实现同步播放呢？另外，在我们的直播系统中，存在一个数据由不同协议分发的问题，并且还要保证时间信息能和数据一同传到观众端。为了解决这个问题，我们使用H.264 SEI自定义帧的方式来进行多流同步。我们通过在H264数据里加入自定义数据，连麦服务器、CDN都会保留这份数据到观众端，在观众端两条流拉下来后，依赖于这样一个流同步的数据来进行多流之间的同步。主播在开播之前，需要从NTP时间服务器来进行对时，对时以后，我们认为多个主播之间有一条时间轴和我们的NTP服务器是同步的，多个流之间就依赖于这个时间轴来进行同步。H.264里的SEI数据是一个留给用户扩展的数据，尤其SEI里类型33的Unregistered SEI，就是我们可以自己扩展的。帧格式如上图所示，这个帧前面有一个4字节的70码，还有一个1字节的帧类型的码，接下来就是SEI类型码，后边是一个BUFFERLENGTH的长度，它是一个动态的公式。在这个PayLoad之后，是一个16字节的UUID，类似于消息类型的格式，每一种应用都会定义自己的UUID来校验不同的消息类型，后面就是自定义的消息，最后有个2字节的尾部。PayLoadSize是动态的，每增加255字节，则多一个字节的BufferLength来表示这个BufferLength，这样是为了避免数据帧里边的数据和提示码会进行竞争，也是SEI的标准规范的一个方式。再往下面看，我们在流A的I帧前面加了SEI同步信息，在流B的I帧前面也加了SEI信息，两个流就算在CDN分发上有时间差，播放端依赖于这两个流里的SEI同步信息，也能实现两条流在播放端同步。

d) 传输优化

第三部分是传输优化。观众端在最开始的时候，是通过CDN源站的CDN边缘节点来实现播放的。但是，有一些特殊的业务可能是主播带着大家一起玩游戏，主播把大家的游戏画面投上去，此时需要参与的用户能实时地接收到主播的协同指令，这样就要求游戏的这边拉RTP流，但是它只是单向的拉流，不会向主播端推流，因为游戏过程中，主播是不需要关注其他人的画面的。此外，我们也有在考虑QUIC的建设，依赖于QUIC节点来优化客户端在弱网环境下的流畅率。

e) QUIC的介绍

接下来介绍一下我们在QUIC方面的工作，QUIC是基于UDP的，是Google提供的一个开源项目，集成在Chrome中。由于HTTP网页在弱网环境下的加载是比较低效的，当出现阻塞或卡顿时，后面的数据都不能进行有效的传输。为了提高页面上的响应速度，Google就开发了基于UDP的QUIC，QUIC能提供和TCP+TLS+HTTP/2一样的功能，并且QUIC是基于UDP的有保障的传输，它在内部做了重传机制。此外，YouTube用到QUIC后减少了缓冲， QQ空间在使用了QUIC以后也提高了网页的加载速度，映客直播在使用QUIC后也是能够减少弱网卡顿，并优化弱网秒开和降低卡顿率的。

f) QUIC在直播中的应用

QUIC在映客直播里的应用包括主播端的RTMP or QUIC和播放端的HTTP or QUIC。在这里主要用到它的两个特性，一个是减少了连接时间，优化秒开，一个是改进了丢包算法，优化了弱网卡顿。其中我们所做的工作包括：第一，移植QUIC。QUIC并不是一个协议的形式，它是集成在Chrome中的，因此我们需要把它移植到安卓平台、IOS平台。通过客户端移植QUIC，让内部RTMP支持QUIC，播放器也支持QUIC，我们服务端支持QUIC，可能稍微好一点，由于QUIC Go这样的项目比较容易集成，推流和拉流CDN也支持QUIC。在500Kbps和1%丢包的情况下，主播端使用QUIC和TCP同时进行RTMP推流。观看对比就发现使用QUIC推流，播放基本上是比较流畅的，而使用TCP推流的播放则是非常卡顿的。

三、监控与运营支撑

1、为什么要做直播追踪和运营相关系统？

在这部分，我会介绍一些运营相关的内容。在开发过程中遇到大量的问题时，不能完全依赖开发去定位问题，这时直播流程追踪系统和大数据分析系统都是非常重要的。直播流程追踪系统可以把直播过程中的关键事件进行汇报，在追踪系统上进行逐个排列，出现问题时只要对主播的UUID进行输入，就能定位到出现问题的点，这样一来，能让我们非常容易定位开播失败的原因，而且能把我们的工作量转移出去。在我们进行传输的优化时，要依赖于大数据系统，包括要上新的特性去做A/B测试都要依赖于大数据分析系统。

2、如何做到直播质量每一秒都可追踪？

接下来，通过一个例子来介绍我们如何做到直播质量每一秒都可以追踪。有一天我们发现在APP上有个热门流播放卡顿，我们希望能定位它到底是因为手机性能还是网络引起的问题。我们分为四步来定位这个问题，第一步是收集主播信息，第二步是捕捉卡顿点，第三步是对推流链路系统进行数据分析，第四步是进行问题定位。我们会先把主播当时的采集帧率、推流ID、机型系统等资料进行收集。然后抓到主播的卡顿点后，就要去定位它的时间点，这里用到了就是刚才提到的流里面的SEI信息，通过SEI信息可以换算出卡顿出现的精确时间，这样有助于在大数据系统里定位问题。如上图所示，我们定位到问题发生在11点03分的某一秒，通过查看推流埋点数据发现主播端的采集帧率只有6帧，出现一个很明显的采集帧率下降，但只看这部分是不够的，还可能是其他系统的问题。

与此同时，我们去查看转推服务，发现并没有出现丢包的情况，用户的网络还是非常好的。于是，我们就推测是主播手机性能下降引起的问题，通过回看数据发现，在有观众送礼的时候，礼物特效展示时出现了明显的性能采集帧率的下降。最后的定位的总结就是，主播使用iPhon6S加上IOS11.4长时间开播后出现了手机发热，导致性能下降，从而导致采集帧率下降。我们的解决办法就是针对iPhone6S比较老的机型，我们会对它的一些美颜特效会进行降级、参数调整，让它开销不是那么大。

四、总结及展望

最后这部分就是对我们未来工作的一个思考。首先，我们会推动H.265继续的向前发展，我们已经支持了H.265的CDN直播、RTMP直播、短视频制作，目前正在考虑支持H265的互动直播，目前H.265只在IOS上面硬编做得比较好，既能兼顾效率、性能，也能比较好的用起来，这里可能还存在一些适配的工作量。其次，在QUIC方向上，我们的QUIC源站已经上线了，使用QUIC可以优化秒开和卡顿率。目前，在做的就是QUIC下行边缘节点的建设，因为这就相当于是要去做观众端不同点的建设，还要考虑什么样的观众端适合从我们的QUIC节点来拉流。另外，就是我们的新业务拓展，包括一些交友类、K歌类的业务，我们认为技术是服务于业务的，新的业务拓展代表新的技术挑战。在交友类的APP中，我们考虑音视频通话之间用WebRTC的P2P方式来进行传输，而我们通过在K歌的调研发现可以采用在WebRTC加RMTP的方式来做端上合流、推流，以此来开展一些新的业务，当然这都是我们的一些尝试。最后，我们认为更好的基础网络是新业务推广的基石，到了5G时代，直播形式会更加丰富，会有更多的更精彩的节目展现给大家。

精品文章推荐

技术干货：

基于 WebRTC 的互动直播实践

相关 [webrtc 互动直播] 推荐：