咱们下载完WebRTC源码后想深入分析其源码的话,首先就须要理解WebRTC的目录构造。因为WebRTC的分层工作做的很好,其代码的目录构造也比拟清晰,在理解这个构造后,就能依据想剖析的性能去对应目录寻找须要的源码了。

WebRTC目录分类

WebRTC的源码目录次要能够分为4大类——接口层、业务解决层、音视频解决层和根底反对层。上面咱们先简要意识下各层所蕴含的目录和次要性能。

  • 接口层。蕴含api目录。WebRTC对外的所有接口都在该目录下,所以如果要新增接口,也应该放在这里。
  • 业务解决层。蕴含pc、call、media目录。pc目录中包含PeerConnection座的媒体协商、收集Candidate、音视频数据传输等逻辑解决。call目录次要是“呼叫”相干的逻辑。media目录中包含媒体引擎相干逻辑解决。
  • 音视频解决层。蕴含common_audio、common_video、audio、video目录。common_audio、common_video目录中别离是音频和视频算法相干代码。audio、video目录别离是音频和视频流相干代码。
  • 根底反对层。其余目录都属于这层。次要都是一些根底模块代码以及编译工具等。

另外还有一个很重要的目录就是modules,这个目录中内容将在后文介绍。

WebRTC目录构造

上面这个表格就是WebRTC中蕴含的所有目录及其性能介绍。

ps:以下目录构造次要是基于Windows平台下的WebRTC的m84版本,其余平台下的其余版本会略有差异,总体大同小异。

目录性能
api接口层,提供对外接口。
audio音频流相干。
baseChromium根底代码,包含线程,零碎信息等。
build编译脚本和BUILD.gn等文件,不同平台下会有不同。
build_overrides提供一些可配置化的参数,能够定制化编译。
buildtoolsgn等编译工具,不同平台下载不同的gn。
call数据流管理层,每一个call都代表同一个端的所有数据的流入流出。
common_audio音频算法相干,包含环形队列、FIR滤波器等。
common_video视频算法相干,包含libyuv、sps/pps分析器等。
data测试数据。
docs文档,包含faq等。
examples示例代码,各种demo。
logging日志。
media媒体引擎层,包含音频、视频引擎等,次要用于音视频的管制。
modulesWebRTC子模块,包含音视频采集、解决、编解码等。
p2pNAT穿透实现,turn、stun等。
pcPeer Connection连贯相干的业务逻辑。
resources测试数据和资源。
rtc_baseWebRTC根底代码,包含线程、锁、网络等。
rtc_tools网络监测、音视频剖析等脚本
sdk挪动端音视频采集、渲染等代码,蕴含Android和iOS
stats数据统计相干。
style-guide编码标准
system_wrappers零碎相干封装,包含cpu个性、读写锁、时钟等
test单元测试
testinggmock、gtest等测试工具代码
third_party第三方依赖库,不同平台下依赖库会有不同。
toolsChromium工具汇合
tools_webrtcWebRTC工具汇合
video视频流相干。

modules目录

modules目录是WebRTC源码中最重要的一个目录。该目录中寄存的都是一些性能比拟独立的模块。包含音视频的采集,解决,编解码器,混音、回声打消、降噪等性能的实现。

上面这个表格就是modules目录蕴含的子目录及其性能介绍。

子目录性能
audio_coding音频编解码
audio_device与设施无关的音频采集、播放等
audio_mixer混音
audio_processing音频前后解决
congestion_controller拥塞管制,Transport-CC等
desktop_capture桌面采集
includemodule头文件
pacing码率探测和平滑解决
remote_bitrate_estimator远端带宽评估
rtp_rtcprtp/rtcp协定
third_party第三方依赖,fft、g711等
utility线程相干工具
video_capture视频采集
video_coding视频编解码
video_processing视频前后解决

须要留神的是remote_bitrate_estimator中的Goog-REMB算法是接收端的拥塞控制算法,曾经被淘汰了,只是为了兼容老版本还保留着。新的拥塞控制算法Transport-CC(GCC)是在发送端评估的,其体现要比接收端的评估算法更优良。