、前言

2017 年 12 月，微信小程序向开发者开放了实时音视频能力，给业内带来广阔的想象空间。连麦互动视频直播技术在 2016 年直播风口中成为视频直播的标配，然而只有在原生的 APP 上才能保障良好的用户体验。
那时候，在微信小程序中无法进行实时音视频互动。微信小程序在去年 12 月宣布开放实时音视频能力，再加上去年 6 月苹果宣布即将支持 WebRTC，业内一下子千树万树梨花开，前途一片光明。
连麦互动直播技术和微信小程序以及 WebRTC 能产生怎么样的化学作用？开发者在微信小程序或者浏览器 WebRTC 上实现连麦互动直播技术的时候，需要知道什么和考虑什么？
连麦视频直播的客户端主要包括：原生 APP、浏览器 H5、浏览器 WebRTC、微信小程序。浏览器上的应用包括 H5 和 WebRTC，前者可以拉流观看，后者可以实现推流和拉流。

2、视频直播客户端技术之Native APP

原生 APP 终端音视频引擎的结构框图如下，基本包括了音频引擎、视频引擎和网络传输，合称实时语音视频终端引擎。这里还包含底层的音视频采集和渲染，还有网络的输入输出能力，这是操作系统开放的能力。

原生 APP 有个天然的好处，它是直接和操作系统打交道的，操作系统开放的资源和能力它都可以直接用，比如说音视频的采集渲染，还有网络的输入输出。套用一句时髦的广告语：“没有中间商赚差价”，直接和操作系统对接，可以获得比较好的用户体验。
在原生 APP 上实现连麦直播的优势是，对上面所说的七个环节有较好的把控，可以获得比较低的延迟，能自研实现语音前处理 3A 算法，包括回声消除，还有对抖动缓冲策略和码率自适应的策略都有比较好的把控。另外，可以自主选择使用 RTMP 协议还是基于 UDP 的私有协议，对抗弱网环境更加有保障。
市面上比较流行的前处理技术，比如美颜、挂件、变声等，原生 APP 都可以通过开放前处理接口让开发者实现或者对接这些技术。为什么要强调这个呢？因为浏览器 WebRTC 和微信小程序都没有开放前处理接口，开发者没有办法自行实现或者对接第三方的美颜或者挂件等技术模块。
在原生 APP 上，开发者可以得到全面的把控能力，让用户可以获得更好的体验。主流的视频直播平台都有自己的原生 APP 平台，而浏览器和微信小程序相对来说是辅助的。原生 APP 的用户体验是最好的，而且对开发者来说也是最可控的。
在原生 APP 上实现连麦直播的劣势是什么呢？开发门槛高，开发周期长、人力成本高。另外，从获取用户和传播的角度来讲，也没有浏览器和微信小程序那么便利。

3、视频直播客户端技术之浏览器（HTML5）

浏览器 H5 就像一个硬币有两面，有好处也有劣势，好处是开发成本低，容易传播，劣势是只能拉流，不能推流，不能做到多个用户连麦直播。另外，在浏览器 H5 上延迟也是比较大。如果使用 RTMP 或者 HTTP-FLV，延迟会在 1 秒到 3 秒之间，如果用 HLS 延迟会大于 8 秒甚至 10 秒，这么大的延迟就根本就不允许实现连麦直播。
使用这三种协议都是通过浏览器 H5 中的播放器来播放的。在多主播连麦互动的场景中，一个播放器里面只能播一路视频流，三个主播就得三个播放器，因此看不到多个主播同框连麦互动的情形。如果要看到多个主播同框互动的画面，就必须把多路流混合成一路流，在单个播放器里面播放。
另外，浏览器 H5 的源代码是开放的。如果在浏览器上把音视频终端引擎实现了，相当于对外公开了所有核心的源代码。因此，还没有见过哪个厂商在浏览器 H5 上完整地把音视频引擎真正做出来。即使你愿意做出来，浏览器也不会允许你这样做，开发者和操作系统之间隔着浏览器，如果浏览器不把操作系统的核心能力开放给开发者，开发者就不能自主采集和渲染，不能掌控网络输入输出，类似流控码控等功能无法实现。
在浏览器 H5 中也可以通过 websocket 来传输，用 jsmpeg 来播放，视频编解码的格式用 mpeg1。
mpeg1 是一个比较老的媒体格式，所有浏览器都支持。在浏览器中使用 jsmpeg 播放器播放 mpeg1，所有浏览器也可以支持。这么做可以获得比较低的延迟，但是还是无法推流，没办法实现连麦直播。

4、视频直播客户端技术之浏览器（WebRTC）

大家可能会觉得很遗憾，浏览器 H5 虽然很容易传播，开发简单但是体验欠佳，不能连麦直播。那么在浏览器上能不能推流，能不能实现连麦直播呢？答案是可以的，那就要用到 WebRTC。
这里说的 WebRTC 是指已经被内嵌到浏览器里面，被浏览器支持的 WebRTC，而不是 WebRTC 的源代码。部分主流浏览器内嵌了 WebRTC，对开发者开放了浏览器的实时音视频能力。
上图是 WebRTC 的结构图。我们可以看到 WebRTC 包括了音频引擎，视频引擎、传输引擎等，最底层的虚线框表示可以重载，也就是说浏览器把最底层的音视频渲染和网络传输的底层能力开放给开发者，开发者可以根据自己的需求选择是否进行重载。音频引擎中，包括了两个编解码器：iSAC 和 iLBC，前者针对宽带和超宽带的音频编解码，后者针对窄带音频编解码。
音频引擎还包括了音频抖动缓冲，回声消除和噪音抑制模块等。抖动缓冲中的 NetEQ 算法可以说是 WebRTC 里面的精华之一。
视频引擎中，包括了 VP8 和 VP9 的视频编解码器，甚至是即将到来的 AV1。视频引擎还包括视频抖动缓冲和图像质量增强等模块。传输引擎，WebRTC 使用的是 SRTP（Secured Realtime Transport Protocol）安全实时传输协议。
最后，WebRTC 采取 P2P 的通信方式，没有媒体服务器等后端的实现。以上是 WebRTC 的简单介绍。
浏览器 WebRTC 一般的优势和劣势这里就不再重复，请大家自行百度，这里只说重点。浏览器 WebRTC 的好处就是实现了相对完整的音视频终端引擎，允许在浏览器上推流，可以实现连麦直播。
然而，浏览器 WebRTC 也有不足：

• 没有开放前处理接口，美颜和挂件这些模块没办法接入第三方的或者自研方案；
• 媒体服务器后端没有实现，开发者要实现媒体服务器，然后通过开源 WebRTC 网关（比如说 janus）接入；
• 编解码器、抖动缓冲和语音前处理 3A 等能力只能依靠 WebRTC，不能自行定制化；
• 部分主流浏览器是不支持 WebRTC 的，特别是苹果的浏览器。虽然说去年苹果宣布支持 WebRTC, 但是目前 iOS Safari 最新版本对 WebRTC 的支持并不好，iOS Safari 的主流版本并不支持 WebRTC，在 iOS 上面微信浏览器也是不支持 WebRTC 的。

由于 WebRTC 不提供媒体服务器的实现，因此需要把浏览器 WebRTC 接入到媒体服务器后端，这个可以是自研的，也可以是第三方的服务。浏览器 WebRTC 和媒体服务器后端之间的协议和媒体格式是不一样的，因此要做协议和格式的转换。WebRTC 用的基于 UDP 的 SRTP，需要把它转换成媒体服务器的基于 UDP 的私有协议。另外，媒体格式也需要转换，因为 WebRTC 中语音视频格式默认用的是 VP8 或者 VP9。同时实时传输网络中有关信令调度也需要做一些调整。浏览器 WebRTC 和媒体服务器后端之间的接入层也可以采用开源的 WebRTC Gateway（比如说 janus）来实现。
浏览器是类似操作系统的一种超级应用，它坐拥重要的流量入口，然而它也是开发者和操作系统之间的“中间商”。开发者通过 WebRTC 获得浏览器开放的实时音视频能力，然而也必须要承受 WebRTC 带来的痛苦。

5、视频直播客户端技术之微信小程序

微信小程序是什么？是跑在微信上面的轻型应用。微信是什么？是类操作系统的超级应用。这些特征和浏览器以及 H5 是不是很接近？H5 是浏览器支持的轻型应用，而浏览器是类操作系统的超级应用。浏览器背后是各大国际科技巨头，不像微信这样背后只有腾讯一个互联网巨头。因此，从这个角度来看，微信小程序、浏览器 WebRTC 和 H5 是有相通之处的。
微信小程序可以类比为浏览器 H5 那样的客户端和服务器的结构。其中 HTML 对应微信小程序的 WXML，CSS 对应小程序的 WXSS，小程序的脚本语言和 JS 是一样的，只是框架不一样。微信小程序提供了两个标签，一个是<live-pusher>，一个是<live-player>。<live-pusher>就是推流，<live-player>就是拉流，可以实现单向直播或者连麦直播。小程序提供两种模式：LIVE 和 RTC，LIVE 支持单向直播，RTC 支持低延迟的连麦直播。目前微信小程序推流采用 RTMP 协议，如果要和私有协议互通，需要进行协议转换。

微信小程序开放了实时音视频能力，对业界来说是重大利好。然而，根据上面的信息和逻辑，我们也看到采用微信小程序实现连麦互动直播的好处和不足。
好处有三点：

• 1）开发成本低，开发周期短，基本和 H5 的开发难度差不多；
• 2）很容易传播和获客，充分利用好微信的优质流量；
• 3）可以推流和拉流，允许实现连麦直播和实时语音视频通话。

不足有四点：

• 1）你会受制于微信小程序的实时音视频能力，比如说，如果它的回声消除有某些问题，你只能等微信团队按照自己的节奏来优化，而自己没有任何办法去优化；
• 2）小程序没有开放前处理接口，只能使用小程序自带的美颜或者变声功能（如果有），不能对接自行研发或者第三方的美颜或者变声模块；
• 3）通过 RTMP 协议推流和拉流，不能和基于 UDP 的私有协议互通连麦。如果要实现和基于 UDP 的私有协议互通连麦，就必须要增加接入层来转换协议格式甚至媒体格式；
• 4）没有实现后端媒体服务器，开发者必须要自行实现媒体服务器，或者把微信小程序接入到第三方的实时通信网络。

浏览器通过 WebRTC 开放了浏览器的实时音视频能力，而微信通过小程序开放了微信的实时音视频能力，在两个类操作系统的平台上允许开发者去实现连麦直播和实时音视频通话。然而，无论 WebRTC 还是小程序只是在终端上带你入门，对开发者来说，要真正实现整套系统，还有很多工作需要做的。
如果要将微信小程序接入实时音视频传输网络，中间得有接入服务器，我们叫接入层。在接入层我们需要做协议的转换，比如说，如果实时音视频传输网络是使用基于 UDP 的私有协议，那么要把 RTMP 协议转为基于 UDP 的私有协议。还有媒体格式的转换，如果和实时传输网络的媒体格式不一样，还需要进行转换。

6、视频直播客户端技术之WebRTC 通过WebView接入小程序

还有别的方法在小程序上做连麦直播互动吗？必须要使用微信小程序开放的语音视频能力吗？也不一定。下图展示了我在市面上看过的一个技术方案，它绕过了微信小程序实时语音视频能力，通过微信小程序 WebView 组件实现了连麦直播的方案。这里和大家分享一下。

这个方案的基本思路是利用 WebView 的浏览器特点，在 WebView 内使用 WebRTC 的 Web API，从而在小程序上获得实时音视频能力。上图是这个方案的架构图。最底层是微信小程序的基础能力。上一层是 WebView，微信小程序的 WebView 类似浏览器，那么就可能会支持 WebRTC。然而必须要注意到，微信小程序的 WebView 在安卓平台上支持 WebRTC，但在 iOS 平台上面不支持 WebRTC。
虽然这个方案理论上也能在微信小程序上实现连麦直播，但是它有以下的局限性：

• 1）在 iOS 平台上，微信小程序不支持这个方案，上面已经说过；
• 2）小程序 WebView 不是完整的浏览器，要比普通浏览器表现差而且有很多的限制；
• 3）开发者和操作系统之间隔了好几层：微信底层，小程序，WebView，WebRTC，然后才是开发者的小程序应用。每一层的抽象都会带来性能上的消耗，都会影响到最终的体验。

这个方案本质上还是一个基于 WebRTC 的解决方案，没有用到微信小程序开放的实时音视频能力，而是快速地借助 WebView 组件，剑走偏锋，十分讨巧地在微信小程序里使用了 WebRTC。

7、本文小结

连麦直播技术逐步在原生 APP, 浏览器 H5，浏览器 WebRTC，微信小程序上延伸，衍生出更加丰富的生态，提供更加便捷和良好的用户体验，对视频直播平台和用户来说是好消息。然而，欲带皇冠，必承其重。特别是在浏览器 WebRTC 和微信小程序上，开发者要充分理解这些类型终端的特点和局限，才能更好地在上面利用连麦直播技术进行创新，服务用户。

喜欢的朋友可以后台私信【1】获取学习视频

附上一份音视频学习课程大纲给大家

然Flash播放器为互联网互动立下汗马功劳，但不得不承认其插件在性能和安全性上都已经远远落后时代，跨设备体验糟糕透顶。在Youtube于今年初将默认网页视频转换成HTML5后，亚马逊旗下的知名游戏直播平台Twitch也开始从Flash向HTML5迈步。据称，虽然视频仍然为Flash格式播放，但目前Twitch的默认播放控件已经全面转换成HTML5播放器，“这是实现全面转换的重要一步。”

相信有不少热衷于游戏的玩家经常在Twitch上收看玩家的游戏直播，相信转换至HTML5播放器后Twitch的流畅度和安全性会提升不少，播放界面也已经经过全新设计，简洁便利不少，自适应比特率功能也能够让玩家更流畅地根据自身网速收看直播。

(来源：cnbeta）

锋网按：本文作者蒋海兵，趣拍产品总监，直播行业老兵。

移动直播行业的火热会在很长一段时间内持续，通过和各行业的整合，从而成为具有无限可能性的行业。主要有以下三个原因：

第一，移动直播的UGC生产模式比PC端的直播更明显，人人都有设备，随时随地开播，完全顺应了互联网时代的开放性原则，能刺激更多人去创造和传播优质内容。

第二，网络带宽和速度在逐渐提高，网络成本在逐渐下降，为移动直播提供一个极佳的发展环境。文字、声音、视频、游戏等都会在移动直播中呈现，创造出更加丰富的用户体验。直播可以以SDK的形式接入到自己的应用中，比如，教育领域中的课后辅导完全可以以直播的形式开展业务、电商也可借助直播让用户挑选商品，促进销售。

第三，一个与VR/AR技术相结合的移动直播为整个行业的未来提供了新的发展空间。VR/AR直播能够让用户身临其境，带动主播与观众更贴近真实的互动，大大提高平台的用户参与度。

当下，有技术实力和流量优势的互联网从业者都不愿错过直播这个风口，如何快速搭建一个直播系统成了大家关心的问题，我想和大家分享下我的经验。我从事于一家直播产品开发商，我们的产品为了快速赶上市场，使用了云服务提供商的直播SDK。

从业者都知道，一个完整直播产品应该包含以下环节：推流端（采集、前处理、编码、推流）、服务端处理（转码、录制、截图、鉴黄）、播放器（拉流、解码、渲染）、互动系统（聊天室、礼物系统、赞）。 下面我就一一讲述下直播SDK在各个环节所做的工作。

一、移动直播推流端需要做哪些工作？

直播推流端即主播端，主要通过手机摄像头采集视频数据和麦克风采集音频数据，经过一系列前处理、编码、封装，然后推流到CDN进行分发。

1、采集

移动直播SDK通过手机摄像头和麦克风直接采集音视频数据。其中，视频采样数据一般采用RGB或YUV格式、音频采样数据一般采用PCM格式。采集到的原始音视频的体积是非常大的，需要经过压缩技术处理来提高传输效率。

2、前处理

在这个环节主要处理美颜、水印、模糊等效果。美颜功能几乎是直播的标配功能。我们调研中发现太多case是因为没有美颜功能被抛弃使用的。另外国家明确提出了，所有直播都必须打有水印并回放留存15天以上。

美颜实际上是通过算法去识别图像中的皮肤部分，对皮肤区域进行色值调整。通过颜色对比找到皮肤区域，可以进行色值调整、添加白色图层或调整透明度等来达到美白效果。在美颜处理方面，最著名的GPUImage提供了丰富的效果，同时可以支持iOS和Android，支持自己写算法实现自己最理想的效果。GPUImage内置了120多种常见滤镜效果，添加滤镜只需要简单调用几行代码就可以了。

3、编码

为了便于手机视频的推流、拉流以及存储，通常采用视频编码压缩技术来减少视频的体积，现在比较常用的视频编码是H.264。在音频方面，比较常用的是AAC编码格式，其它如MP3、WMA也是可选方案。视频经过编码压缩大大提高了视频的存储和传输效率，当然，经过压缩后的视频在播放时必须进行解码。

相较于之前的H.264，2012年诞生的H.265编解码标准有了相当大的改善，做到了仅需要原来一半带宽即可播放相同质量的视频，低于1.5Mbps的网络也能传输1080p的高清视频。像阿里云、金山云都在推自己的H.265编解码技术，随着直播的快速发展和对带宽的依赖，H.265编解码技术已有全面取代H.264的趋势。

H264和H265个模块技术差异：

另外，硬件编码已经成为移动直播的首选方案，软编码处理在720p以上的视频颓势非常明显。在iOS平台上硬件编码的兼容性比较好，可以直接采用，但在Android平台上，Media Codec编码器针对不同的芯片平台表现差异还是非常大的，要完全实现全平台兼容的成本还是非常高的。

4、推流

要想用于推流还必须把音视频数据使用传输协议进行封装，变成流数据。常用的流传输协议有RTSP、RTMP、HLS等，使用RTMP传输的延时通常在1–3秒，对于移动直播这种实时性要求非常高的场景，RTMP也成为移动直播中最常用的流传输协议。最后通过一定的Qos算法将音视频流数据推送到网络断，通过CDN进行分发。在直播场景中，网络不稳定是非常常见的，这时就需要Qos来保证网络不稳情况下的用户观看直播的体验，通常是通过主播端和播放端设置缓存，让码率均匀。另外，针对实时变化的网络状况，动态码率和帧率也是最常用的策略。

当然，在网络传输方面全部自己来做基本不现实，找提供推流服务的CDN服务商提供解决方案是最好的选择。据了解，阿里云是国内唯一能自研CDN缓存服务器的厂商，性能非常有保障。当然，大多数直播平台都会同时接入多个视频云服务提供商，这样可以做拉流线路互备，对推流后视频集群再进行优化也可提高直播的流畅性和稳定性。

二、服务端处理需要做哪些工作？

要想适配各终端和平台，服务端还需要对流进行转码，如支持RTMP、HLS、FLV等格式拉流，支持一路转多路适配不同网络和分辨率的终端设备。

1、截图、录制、水印

像阿里云等云服务商都提供了实时转码技术，将用户推流码率较高（比如720P）实时转化成较低清晰度（比如360P）的流以适应播放端的需求。如果要自己搭建实时转码系统，这个成本是极高的，一台8核设备只能实时转10路流，如果一个正常的直播平台有1000路流，就需要100台设备，加上后期的运维成本，一般公司就吃不消了。

2、鉴黄

2016年4月14日，文化部查出了斗鱼、虎牙、YY、熊猫TV、六间房、9158等涉嫌提供含宣扬淫秽、暴力、教唆犯罪的网络直播平台，被列入查处名单。政府介入管制有利于直播行业打造健康的生态，进入良性发展。这也意味着为了安全直播产品鉴黄成了必需环节，使用技术手段去鉴黄是移动直播平台必然采用的方案。

市面上提供鉴黄服务的方案主要有两种：

第一种是对视频进行截图，然后对图片进行鉴黄，返回鉴黄结果和分值。典型的企业有阿里（绿网）、图谱科技，他们目前都支持直接传入视频，经过服务端分析返回结果。通常由业务系统接入鉴黄服务，根据鉴黄结果对直播流进行控制，如切断直播流、封禁账号等。

第二种是和CDN结合，直接对直播流进行分析，识别结果分为色情、疑似色情、性感和正常，业务系统根据识别结果直接控制直播流。典型的企业是Viscovery，这套方案的优点是实时性保证比较好，缺点是必须部署到CDN或自己的机房，使用成本相对高一些。

还有一种一站式直播解决方案提供商，他们的做法是，用户只需在控制台对鉴黄服务进行配置就可以针对每个应用、每一路直播流进行实时审核。在控制台中，云服务商实时将鉴黄结果返回，用户可以直接查看色情直播和违规界面的截图，同时可以对直播流进行控制，切断问题直播流。该服务商还提供了短信、邮件和站内信功能，避免漏掉任何一个非法视频，给平台造成损失，我们就使用了这种方式。

三、播放器端需要做哪些工作？

在播放器端如何做到秒开，直播过程中保证画面和声音清晰度的同时，稳定、流程、无卡顿的直播流量，这些工作都需要播放器端配合服务端来做优化，做到精确调度。

1、拉流

拉流实际是推流的逆过程。首先通过播放端获取码流，标准的拉流格式有RTMP、HLS、FLV等。RTMP是Adobe的专利协议，开源软件和开源库都支持的比较好，如开源的librtmp库，播放端只要支持flashPlayer的就能非常简单的播放RTMP直播，直播延迟一般在1–3秒。

HLS是苹果提出的基于HTTP的流媒体传输协议，HTML5可以直接打开播放，通过微信、QQ等软件分享出去，用户也可以直接观看直播，可以说移动直播app，HLS拉流协议是必须支持的，缺点是延迟通常大于10秒。FLV（HTTP-FLV）协议是使用HTTP协议传输流媒体内容的一个协议，也不用担心被Adobe的专利绑架，直播延迟同样可以做到1–3秒。

各拉流协议的差异：

我们使用的云服务的直播拉流技术提供了以上三种格式，满足不同业务场景的需求，如对即时性要求较高或有互动需求的可以采用RTMP或FLV格式进行直播拉流播放；对于有回放或跨平台需求的，推荐使用HLS。当然，三种协议是可以同时使用的，分别用到自己的场景就可以了。

2、解码和渲染

拉流获取封装的视频数据后，必须通过解码器解码、渲染后才能在播放器上播放。它是编码的逆过程，是指从音视频的数据中提取原始数据。前面介绍的H.264和H.265编码格式都是有损压缩，所以在提取后的原始数据，并非原始采样数据，存在一定的信息丢失。因此，在视频体积最小的情况下通过各种编码参数保留最好的原始画面，成为了各视频公司的核心机密。

考虑对高清的支持，解码肯定还是要选择硬解码的。前面介绍过，iOS系统由于硬件比较单一、比较封闭，支持的比较好，Android系统由于平台差异非常大，编解码要完全兼容各平台还需要很多工作要做。

四、移动直播中的交互系统

移动直播中最常见的交互有聊天室（弹幕）、点赞、打赏和礼物等，交互系统涉及消息的实时性和互动性，在技术实现上大多是使用IM的功能来实现的。对于在线人数比较多的房间，弹幕消息量是非常大，主播与用户其实都看不过来，为了缓解服务器压力，在产品策略需要做一些必要的优化。

1、聊天室

移动直播中的弹幕交互是用户和主播互动的主要方式，实际上就是IM中的聊天室功能。聊天室和群聊功能类似，但聊天室的消息是不需要分发给不在线的用户的，历史消息也不需要查看，用户只有进入聊天室后才能查看聊天消息和群成员信息。面对复杂多变的网络状况，还需要根据用户位置就近选择近对应运营商的单线机房接入弹幕消息服务，让弹幕更及时。

2、礼物系统

礼物系统更是绝大多数移动直播平台的标配了，它是这些平台主要的收入来源。送礼物的形式也增强了用户和主播之间的互动交流，也是主播依赖平台的最主要原因。

礼物的收发在技术实现上也是用聊天室接口做的，通常采用IM中的自定义消息实现，当用户收到或发送礼物时将自定义消息对应的礼物图形渲染出来。

以上就是我们在使用了第三方SDK服务后总结出来的直播产品经验，希望能帮助到创业者和从业者们。