WebRTC | 原理、架构、框架目录、运行机制、核心类、PeerConnection调用过程等详解...

架构

  • 整理分为两层:
    应用层、核心层

  • 绿色部分是核心部分,
    是WebRTC提供的核心功能;

  • 紫色部分是浏览器提供的JS的API层;

    浏览器对WebRTC核心层的C++ API 做了一层封装,
    封装成了JS接口;

  • 最上面的箭头是上层应用了,
    上层应用 可以在 浏览器中 直接访问 浏览器提供的API;

  • 最终调用到核心层【蓝色虚线框、可重载!!】

WebRTC核心层

  • C++ API:API数量较少,主要是PeerConnection;
    (PeerConnection的API又包含传输质量、传输质量报告、各种统计数据、各种流等)
    【设计技巧:
    对于上层来说,提供的API简单,方便应用层开发;
    内部比较复杂;】

  • Session层【上下文管理层】:
    如应用创建了音频、视频、非音视频的数据传输,
    都可以在Session层做处理,做管理相关的逻辑;

  • 【最重要】引擎层/传输层【核心】

    • 音频、视频、传输 解耦

    • 音频引擎:【Voice Engine】
      ISAC/ILBC 编解码;
      NetEQ 【Buffer】 网络适配、防止网络抖动;
      回音消除(echo canceler):
      音视频重点,决定产品质量,
      WebRTC里提供了相关非常成熟的算法,开发时只需要调节参数即可;
      降噪(Noise Reduction)、自动增益;

    • 视频引擎:【Video Engine】
      VP8、openH264 编解码;
      Video jitter buffer:防止视频抖动;
      Image enhancements:图像增强;

    • 传输【Transport】
      底层用的UDP,上层用的SRTP【即安全的、加密后的RTP】;
      Multiplexing:多个流复用同一个通道;
      P2P层【包括 STUN+TURN+ICE】;
      所有的
      音频视频的接收与发送,
      都是通过传输层去做的,
      传输层包括了泄漏的检测、网络链路质量检测,
      根据情况估算网络带宽,根据网络带宽进行音视频、文件等非音视频的传输;

  • 硬件层
    视频采集、渲染;
    音频采集;
    网络IO等;
    WebRTC的核心层中是没有视频的渲染的,
    所有的渲染都需要 应用层 或者 浏览器层 自己做;



WebRTC目录结构

  • WebRTC代码量大,目录多
  • 实际开发中,可能需要我们修改WebRTC的代码,
    所以,我们必须知道每个目录的功能、作用是什么;


补充说明

  • call,一个端一个call,多个端多个call;

  • module目录很大,也特别重要,
    里边有很多子模块,
    每个子模块也都非常重要;


  • pc:【重要目录,上层的一个统一接口层】
    Peer Connection,代表一个连接,
    连接下边就要有很多相关API了,
    如,
    Stream 流;
    chain 轨【音频轨、视频轨、桌面轨】
    【轨 即 一系列永不相交的平行线(线程),
    即音频与视频与桌面处理,都是各自处理,互不交叉的】;

    所以在Peer Connection中我们可以拿到
    通过我们可以拿到每一个多媒体
    还可以拿到所有媒体的统一信息、传输的统一信息

  • p2p:
    端对端的传输时,需要先检查p2p是否能打通;
    相应的协议、工具、API等,放在这里;

  • rtc_base
    不同操作系统,如Window和Linux,之间的系统函数差别就特别大;
    但是rtc_base都封装好了,
    上层按照规范编写调用逻辑即可,
    框架会判断是在哪个平台运行,并执行相应的代码;

  • rtc_tool是音视频相关的测试;
    tool_webrtc是整个框架的测试;

  • system_wrappers
    存放操作系统等操作代码,
    不同系统不同文件存放;

以上是WebRTC最外层的目录,
下面看WebRTC目录下的Modules子目录

WebRTC Modules 目录

  • audio_coding:
    上面的WebRTC架构图中
    提到的 ISAC/ILBC、VP8等编解码器逻辑,
    都是放在这个目录下的;

  • audio_device:
    现在的WebRTC文件中关于Android、IOS的部分都放在sdk目录下了,
    而之前的话,
    所有的设备类型包括Android、IOS、Window、Mac、Linux的逻辑都是在audio_device目录下的;
    现在的话Android、IOS被提取出去,
    这里放的是关于Window、Mac、Linux的文件;

  • audio_mixer:
    混音的概念:
    比如现在有几个用户同时在说话,
    这样子会产生多个音频流
    WebRTC则会把这几个音频流混合在一起,
    这样子在传输的时候就比较方便,
    减少了音频流总数;
    那这个混音相关的逻辑文件,就放在audio_mixer这里;

  • audio_processing:
    音频前后处理:指回音消除、降噪、增益等处理操作;

  • bitrate_controller:码率、码流控制;

  • congestion_controller
    当我们检测到网络流量比较高的时候,
    我们要做一些流量控制
    防止网络包把带宽打死;
    相关处理逻辑 则 放在本文件夹下;

  • 探测码率之后,对码率做一个均衡的平滑的处理,再发送交互;

  • video_processing:
    视频前后处理:指回音消除、降噪、增益等处理操作;
    如增加人脸识别功能也可以放在这个目录下;


WebRTC的运行机制

  • Track
  • 视频与音频是不相交的,单独存放;
  • 两路音频也是两路轨,不相交;
  • MediaStream
  • 借鉴了传统媒体流的概念;
    传统媒体流中也包括了音频轨、视屏轨等;
WebRTC重要的类
  • MediaStream
    传输媒体数据;

  • RTCPeerConnection【核心】
    这个WebRTC中最为重要的类,
    是一个大而全的类,包含了很多重要的功能;

    设计优势:
    在应用层应用时方便,
    只需要创建一个RTCPeerConnection连接,
    然后把一个MediaStream媒体流搭载上去,
    随后的细节就不用管了,
    其中所有的传输、寻路等细节,
    都由RTCPeerConnection内部封装实现了,底层封装做了很多相关的工作;

  • RTCDataChannel
    非音视频的数据(如文本文件、二进制数据等),都通过RTCDataChannel来传输;
    RTCDataChannel是通过RTCPeerConnection获取的;
    传输非音视频的数据时,
    应用层要做的,
    就是拿到一个RTCDataChannel对象,把数据搭载上去即可;


PeerConnection调用过程

  • Worker 线程、Signaling线程,
    创建PeerConnectionFactory
    PeerConnectionFactory可以
    创建PeerConnectionLocalMediaStreamLocalVide/AudioTrack等;

  • 多方进行通讯时,
    每一方(每一个参与单位)都是对应一个Stream;

调用时序图

  • 首先应用层Application【注意这里Application本身就是一个PeerConnectionObserver】,
    创建出一个PeerConnectionFactoryCreatePeerConnectionFactory】;

  • PeerConnectionFactory触发CreatePeerConnection
    CreateLocalMediaStreamCreateLocalVideoTrackCreateLocalAudioTrack
    创建了PeerConnectionMediaStream等等实例;

  • 然后通过AddTrack
    把各种轨(track)加到流(LocalMediaStream)中去,
    然后通过AddStream
    把流加到PeerConnection中;

  • 流加到连接之后,
    会通过CommitStreamChanges提交流的变化;
    当流发生变化的时候,
    会触发OnSignalingMessage事件,创造出一个offer【SDP描述信息】;

  • 有了offer【SDP描述信息】之后,
    就会通过应用层【Application】,通过信令,
    发送到远端【Send offer to the remote peer】;

【SDP描述信息】内容:
有哪些音视频数据,音视频数据的格式分别是什么,传输地址是什么等;

  • 远端收到数据后,则根据offerSDP,
    回复一个answerSDP【Get answer from the remote peer】,
    交给本地信令;

  • 信令收到远端的answerSDP之后,
    会把信息传给本地PeerConnectionProcessSignalingMessage】,
    本地PeerConnection就会拿到对方的媒体流信息、传输端口、传输地址;

至此,远端和本地就打通连接,
可以相互传媒体数据

  • 远端数据来的时候,
    PeerConnection还会将远端的流添加到Application中去;
    【OnAddStream(注意区分AddStream)】











参考自:

  • 2
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

凌川江雪

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值