1. 音视频直播的两条技术路线：

自古以来人类就需要音视频技术。

压缩技术解决了（音频、视频压缩编解码器）、高速公路建成了（带宽提升，光纤、4/5G），接下来就是如何利用这些技术进行产品化了。

“音频频直播” 就是众多音视频应用中最亮眼，也是大家最需要的应用。

对于不同的行业和领域，在使用音视频直播时，人们往往给直播不同的称谓，例如：在教育领域中的直播称为 “在线教育直播”，在远程办公领域的直播称为 “网络音视频会议”，在娱乐领域的直播称为 “娱乐直播”，等等。

虽然所有的 直播 底层都是使用 音视频技术 + 网络传输技术，但是由于应用场景的不同、目标不同，所以它们的技术方案也有很大的区别。

1. 对于 音视频会议 而言，它关注的是实时通话的质量，也就是当你一开启摄像头、打开麦克风后，远端的用户就可以立即看到你的视频、听到你的声音（也就是对直播的实时性、低时延 要求很高）；
2. 而娱乐直播与音视频会议不同，它追求的目标是 让尽可能多的用户看到节目，视频清晰、不卡顿，但它对音视频延迟要求不高，因此这类直播的实时性比较差（也就是对直播的 用户量、并发数、视频质量 要求很高）。

由此，我们可以知道视频直播分成了两条技术路线：
一条是以 音视频会议 为代表的 实时互动直播；
另一条是以 娱乐直播 为代表的 流媒体分发。

这两种技术各有优缺点：互动直播主要解决人们远程音视频交流的问题，所以其优点是实时性强，时延一般低于500ms；而娱乐直播则主要解决音视频的大规模分发问题，因此其在大规模分发上更具优势，但实时性比较差，通常时延在3s以上。

表1.1中是目前常见的几种直播技术：

在表1.1中，只有WebRTC技术用于实时互动直播，而其他几种技术都用于娱乐直播。

实际上，最初娱乐直播也只有RTMP这一种方案可选，但后来由于苹果宣布不再支持RTMP，并推出了自己的解决方案HLS，最终导致RTMP走向了消亡。

RTMP（Real Time Messaging Protocol，实时消息传输协议），是Adobe公司开发的私有协议（没有完全公开）。该协议基于TCP，是一个协议族，包括 RTMP基本协议 及 RTMPT/RTMPS/RTMPE等多种变种。RTMP是Adobe公司为Flash播放器和服务器之间音频、视频和数据传输开发的开放协议。

HLS（HTTP Live Streaming，基于HTTP的自适应码率流媒体传输协议）是基于HTTP的，它首先对媒体流（文件）进行 切片，然后通过HTTP传输，接收端则需要将接收到的切片进行缓冲，之后才能将媒体流平稳的播放出来。
基于上述机制（发送端分段下发，接收端缓冲后播放），HLS在实时性方面比RTMP差很多，但使用它的好处也是显而易见的（苹果产品原生支持），而且娱乐直播本来也对实时性要求不高，因此这种方案被大家广泛采纳。

然而，将RTMP换成HLS需要付出高昂的成本，于是有人提出了 HTTP-FLV方案，即传输的内容仍然使用RTMP格式，但底层传输协议换成HTTP（RTMP原本是基于TCP底层传输），这种方案既可以保证其实时性比HLS好，又可以节约升级的成本。

但是HTTP-FLV的劣势是扩展性比较差，因此只是一个临时方案。HLS方案虽然不错，但是其他公司也有类似的方案，这导致各直播厂商不得不写多套代码，费时费力。基于这种情况，FFMPEG推出了DASH方案，DASH方案也是以 切片 的方式传输数据（与HLS类似），该方案最终成为国际标准，从而使直播厂商只要写一套代码就可以实现切片传输了。

音视频直播的现状与未来：

音视频直播有两个重要趋势：
一是实时互动直播技术与娱乐直播技术合二为一；二是WebRTC已经是直播技术的标准，大家都在积极的拥抱WebRTC。

WebRTC目前已经成为音视频实时通信的标准，而它与浏览器是深度绑定的，因此未来浏览器的功能会越来越强大，强大到我们在终端上不需要安装任何其他软件，只要有一个浏览器就可以完成我们所有的日常工作。

2. 开发一个直播客户端的架构：

一个最简单的直播客户端至少包括 音视频采集模块、音视频编码模块、网络传输模块、音视频解码模块、音视频渲染模块五大部分。

1. 拆分音视频模块：
   在实际开发中，音频与视频的处理是完全独立的，它们有各自的处理方式。因此它们的采集、编码、解码模块也是分开的。
2. 跨平台：
   实现音视频客户端除了要实现上面介绍的7个模块之外，还要考虑 跨平台 的问题，只有在各个平台上都能实现音视频的互联互通，才能称得上是一个合格的音视频直播客户端。
   增加跨平台后，音视频直播客户端的架构较之前复杂多了。要实现跨平台，难度最大也是最首要的是访问硬件设备的模块。
3. 插件化管理：
   直播客户端对不同的音视频编解码器做插件化管理，以此支持多种编码格式，例如音频的Opus、AAC、G.711/G.722、iLBC、Speex 等，视频的H264、H265、VP8、VP9、AV1 等，这样它才能应用的更广泛。
4. 其他：
   除了上面介绍的几点外，要实现一个功能强大、性能优越、应用广泛的音视频客户端还有很多工作要做：
   （1）音视频不同步：
   音视频经网络传输后，由于网络抖动和延迟等问题造成的音视频不同步，对此需要在直播客户端中增加音频和视频同步模块，以保证音视频的同步；
   （2）回音：
   指的是与其他人进行实时互动时可以听到自己的回音。
   在实时音视频通信中，不光有回音问题，还有噪声、声音过小等问题，我们将它们统称为 3A问题。
   这些问题是非常棘手的，目前的开源项目中，只有 WebRTC 和 Speex有开源的回音消除算法，而且WebRTC的回音消除算法是非常先进的；
   （3）音视频的实时性：
   要保证通话质量就必须保证网络质量，TCP是以牺牲实时性来保障网络服务质量的，而实时性又是音视频实时通信的命脉，所以一般情况下的实时直播首选UDP，这就需要自己编写 网络控制算法 以保证网络质量；
   （4）网络拥塞、丢包、延时、抖动、混音等问题。

3A问题：
Acoustic Echo Cancelling(AEC)，回音消除；
Autimatic Gain Control(AGC)，自动增益；
Active Noise Suppression(ANS)，降噪。

通过上面的描述，可见自己研发一套音视频直播客户端的难度，所以使用WebRTC是有必要的。

3. WebRTC客户端架构：

WebRTC的架构大体分为四层：
接口层、Session层、核心引擎层、设备层。

1. 接口层包括两部分：一是Web层接口，二是Native层接口。
   也就是说你既可以使用浏览器开发音视频直播客户端，也可以使用Native（C++、Android、OC等）开发音视频直播客户端；
2. Session层的主要作用是控制业务逻辑，如媒体协商、收集Candidate等；
3. 核心引擎层音频引擎、视频引擎和网络传输层。
   音频引擎包括NetEQ、音频编解码器（Opus、iLBC）、3A等；
   视频引擎包括JitterBuffer、视频编解码器（VP8、VP9、H264）等；
   网络传输层包括SRTP、网络I/O多路复用、P2P等；
4. 设备层主要与硬件打交道，它涉及的内容包括在各终端上进行音频的炒采集与播放，视频的采集，以及网络层等。

WebRTC架构图：

音视频数据流：

4. 音视频实时通信的本质：

由于线上与真实场景存在这样或那样的不同，因此我们可以总结出，音视频实时通信追求的本质是尽可能逼近或达到面对面交流的效果，同时这也是音视频实时通信的目标。

要实现这样的效果，就不得不提两个指标（这也是音视频实时通信中关注的两个指标）：
一是实时通信中的延迟指标；
二是音视频服务质量指标。

4.1 实时通信延迟指标：

在端到端之间，引起延迟的因素有很多，比如 音视频采集时间、编解码时间、网络传输时间、音视频的渲染时间以及各种缓冲区所用的时间等。

在众多延迟因素中，网络传输引起的延迟是动态的，所以其最难以评估、难以控制、难以解决，而其他因素引起的延迟时间则基本是恒定不变的。

4.2 音视频服务质量指标：

业务服务质量包括 音频服务质量 和 视频服务质量。

由于音频数据量比较小，对网络的影响不大，并且3A问题非常复杂，需要专门的介绍，下面主要介绍视频服务质量指标。

与视频服务质量有关的几个基本概念：

1. 分辨率：
   指图像占用屏幕上像素的多少。 图像中的像素密度越高，图像的分辨率越高。
   对于实时通信而言，图像默认分辨率一般设置为 640 * 280 或 640 * 360；
2. 帧率：
   指视频每秒播放帧（图像）的数量。播放的帧数越多，视频越流畅。（如果帧过少，视频就会出现卡顿的现象，停留在一个帧上画面静止，长时间等待下一帧的素材）
   一般动画片/电影的帧率在 24帧/秒 以上，高清视频的帧率在 60帧/秒 以上。对于实时通信的视频来说，15帧/秒 是一个分水岭，当帧率小于 15帧/秒时，大部分人会觉得视频质量不佳，卡顿严重；
3. 码率：
   指视频压缩后，每秒数据流的大小。 原则上，分辨率越大，码率也越大。如果出现分辨率大而码率小的情况，说明在视频编码时丢弃了大量的图像信息，这将导致解码时无法将图像完整复原，造成失真。

用来评估业务服务质量好坏的指标：MOS值（Mean Option Score，平均意见值）：
5 – 优秀，4 – 较好，3 – 还可以，2 – 差，1 – 很差。

举例，当分辨率为 640 * 480时，需要 1900Kbps 的码率；当分辨率为 1920 * 1080 时，需要 7Mbps的码率。

由上述指标可见，要想使在线实时通信可以逼近或者达到面对面交流的效果，就必须 尽可能的降低传输的延迟，同时增大音视频传输的码率。

然而，降低延迟和增大码率是矛盾的，除非所有用户都有足够的带宽和足够好的网络质量，但这显然是不现实的。

4.2 实时通信的主要矛盾：

现实中，我们需要服务许许多多的用户，但每个用户的网络状况参差不齐，而他们却都希望享受较好的实时音视频服务质量。

这就形成了 用户“较差”的网络与接收“较好”的服务之间的矛盾。

更准确的说，是 “音视频服务质量” 与 “带宽大小、网络质量、实时性” 之间的矛盾，而这也是实时通信的主要矛盾。

如何解决这一矛盾，总结起来有以下几种方法：

1. 增加带宽：
   多方通信属于典型的“木桶效应”，通信服务质量的好坏是由网络最差的那个用户决定的；
2. 减少数据量：
   在网络带宽一定的情况下，为了解决实时通信的矛盾，我们必须通过减少数据量来解决这一矛盾。但是减少数据量一定是以牺牲音视频服务质量为代价的，但这就是一种平衡。
   有以下几种方法可用于实现减少数据量的方式保障实时性：
   （1）采用更好的压缩算法：
   （2）SVC技术：
   （3）Simulcast技术：
   （4）动态码率：
   （5）甩帧或减少业务：
3. 适当增加时延；
4. 提高网络质量；
5. 快速准确的评估带宽。

参考内容：
《WebRTC音视频实时互动技术—原理、实战与源码分析》