WebRTC | 音视频直播客户端框架_webrtc 视频直播 服务端 客户端

        端到端通信互动技术可分解为以下几个技术难点：客户端技术、服务器技术、全球设备网络适配技术和通信互动质量监控与展示技术。

一、音视频直播

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

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

1.常见的直播技术

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

        HLS是基于HTTP的，它首先对媒体流（文件）进行切片，然后通过HTTP传输，接收端则需要将接收到的切片进行缓冲，之后才能将媒体流平稳地播放出来。（实际上，最初娱乐直播也只有RTMP这一种方案可选，但后来由于苹果宣布不再支持RTMP，并推出了自己的解决方案HLS，最终导致RTMP走向了消亡。）

        将RTMP换成HLS需要付出高昂的成本，于是有人提出了HTTP-FLV方案，即传输的内容仍然使用RTMP格式，但底层传输协议换成HTTP，这种方案既可以保障其实时性比HLS好，又可以节约升级的成本，因此也受到各方的欢迎。不过HTTP-FLV的扩展性比较差，因此它只是一种临时方案。

        HLS方案虽然不错（有大量的用户使用），但其他公司也有类似的方案，这使得各直播厂商不得不写多套代码，费时费力。于是，FFMPEG推出了DASH方案，该方案与HLS类似，也是以切片的方式传输数据，最终该方案成为国际标准，从而使直播厂商只要写一套代码就可以实现切片传输了。

2.音视频直播的现状

        WebRTC的愿景是让浏览器间可以快速、方便地实现端到端的实时音视频互动。实时互动直播与娱乐直播技术相结合成为现在直播服务器的主流技术方案。

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

二、自研直播客户端架构

1.基本的五大模块

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

        细化一下，音频的采集模块与视频的采集模块是分开的，而音频编解码模块与视频的编解码模块也是分开的。也就是说，音频采用了一条处理流程，视频则采用了另外一条处理流程，它们之间并不相交。在音视频处理中，我们一般称每一路音频或每一路视频为一条轨。

2.支持跨平台

        除上述笼统的五大模块之外，还需考虑跨平台问题。只有在各个平台上都能实现音视频的互联互通，才能称得上是一个合格的音视频直播客户端。以音频采集为例，在不同的平台上，采集音频数据时使用的系统API是不一样的。PC端使用的是CoreAudio；Mac端使用的系统API也称为CoreAudio，不过具体的函数名是不同的；Android端使用的是AudioRecord；iOS端使用的是AudioUnit；Linux端使用的是PulseAudio。

3.编解码的插件化管理

        对于音视频直播客户端来说，我们不但希望它可以处理音频数据、视频数据，而且还希望它可以分享屏幕、播放多媒体文件、共享白板……即使是处理音视频，我们也希望它可以支持多种编解码格式：

• 音频除了可以支持Opus、AAC外，还可以支持G.711/G.722、iLBC、Speex等；
• 视频除了可以支持H264外，还可以支持H265、VP8、VP9、AVI等。

        G.711/G.722主要用于电话系统，音视频直播客户端要想与电话系统对接，就要支持这种编解码格式；Opus主要用于实时通话；AAC主要用于音乐类的应用，如钢琴教学等。实现插件化管理可以很方便的使直播客户端能够支持尽可能多的编解码器。

4.关注其他问题

• 音视频不同步问题

        音视频数据经网络传输后，由于网络抖动和延迟等问题，很可能造成音视频不同步。对此，可在音视频直播客户端增加音视频同步模块以保障音视频的同步。

• 3A问题

        3A是指：Acoustic Echo Cancelling（AEC），即回音消除；Automatic Gain Control（AGC），即自动增益；Active Noise Control（ANC，也称为Noise Cancellation、Noise Suppression），即降噪。

• 音视频实时问题

        TCP是以牺牲实时性来保障网络服务质量的。所以，为了保证实时性，一般情况下实时直播应该首选UDP。

三、WebRTC客户端架构

         从WebRTC架构图中可以了解到，它大体上可以分成四层：接口层、Session层、核心引擎层和设备层。

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

四、自研系统与WebRTC比较