在网上经常看到有人说:“在线教育直播是用WebRTC做的”,“音视频会议是用WebRTC做的”......;“声网、腾讯、阿里......都使用的WebRTC”。但你有没有好奇,这些一线大厂为什么都要使用WebRTC呢?换句话说,WebRTC到底好在哪里呢?
这个问题,对于长期做音视频实时通信的老手来说是不言而喻的;但对于新手,则是急切想知道,而又很难得到答案的问题。那么本文我将采用对比法,向你详细阐述一下WebRTC到底好在哪里。
这次我们对比的指标包括:性能、易用性、可维护性、流行性、代码风格等多个方面。不过,要做这样的对比并非易事儿,首先要解决的难点是,目前市面上没有一款与WebRTC接近或有相似功能的开源库。这真成了无米之炊了!
好在这点困难并难不倒我们,既然没有与之可比较的开源库,那我们就自己“造”一个,用自研系统与WebRTC作比较。评估一下自研系统与基于WebRTC开发的音视频客户端,哪个成本更低、质量更好。通过这样的对比,相信能让你更加了解WebRTC,知道其到底有多优秀了。
自研系统直播客户端架构
首先我们先来了解一下自研直播客户端的架构,其如(图1)所示。这是一个最简单的音视频直播客户端架构,通过这张架构图,你大体可以知道自研系统都要实现那些模块了。
(图1)
由(图1)你可以知道,一个最简单的直播客户端至少应该包括:音视频采集模块、音视频编码模块、网络传输模块、音视频解码模块和音视频渲染模块五大部分。
- 音视频采集模块:该模块调用系统的API,从麦克风和摄像读取设备采集到的音视频数据。音频采集的是PCM数据,视频采集的是YUV数据。
- 音视频编码模块:它负责将音视频设备上采集的原始数据(PCM、YUV)进行压缩编码。网
- 络传输模块:该模块负责将编码后的数据生成RTP包,并通过网络传输给对端;同时,接收对端的RTP数据。
- 音视频解码模块:它将网络模块接收到的压缩数据进行解码,还原回原始数据(PCM、YUV)。
- 音视频渲染渲染:拿到解码后的数据后,该模块将音频输出到扬声器,将视频渲染到显示器。
通过前面的介绍,相信你一定觉得,自研一个直播客户端好像也不是特别难的事儿。但实际上,上面介绍的音视频直播客户端架构是极简化的,甚至都不能称之为直播客户端架构,而只能称它为示意图。因为要将它变为真实的、可商用的架构还需要做不少的细化工作。
拆分音视频模块
接下来,咱们就对上面的直播客户端架构图进行逐步细化,细化的第一步就是拆分音视频模块。因为在实际开发中,音频与视频的处理是完全独立的,它们有各自的处理方式。如音频有独立的采集设备(声卡),独立的播放设备(扬声器)、访问音频设备的系统API等,另外,音频还有多种音频编解码器,如Opus、AAC、iLBC等;同样,视频也有自己独立的采集设备(摄像头)、渲染设备(显示器)、各种视频编码器,如H264、VP8等。细化后的直播客户端架构如(图2)所示。
(图2)
从(图2)中你可以看到,细化后的架构中,音频的采集模块与视频的采集模块是分开的,而音频编解码模块与视频的编解码模块也都是分开的。也就是说,音频是一条处理流程,视频是另外一条处理流程,它们之间并