WebRTC架构介绍

一、概述：

今天开始写点WebRTC源代码相关的！！！！！开整！！！！！

为什么要使用webrtc：

WebRTC（Web Real-Time Communication）即网页即时通信,这个东西, 集成了音视频采集、编码、网络传输等模块，为的是让开发者快速开发出一套基于浏览器的音视频实时通信软件；

应用领域：

到目前为止，不光是基于浏览器开发应用，所有涉及音视频实时直播的（有别于传统直播）都离不开它的影子。比如，音视频会议等。

和传统直播的区别：

传统直播比如你看球赛，看直播软件的小姐姐跳舞，这个是不能有数据丢失的，因为每一帧对你都很重要；实时直播，强调的是实时性，低延迟，比如开会讲话，延迟过大（超过500ms）就说不到一块去了！

二、软件架构：

官方网站：

Architecture | WebRTC

架构图：

可以看出主要分为两大部分:

• 面对web开发者的API层(紫色):

  • 其实主要是定义了一些JS的API,很方便用户调用;

• WebRtc的核心层(绿色):

  • API层: 主要是定义一些C++层的接口;
  • Session层: 会话层,顾名思义,针对应用层用户创建的一些会话进行管理;
  • 引擎层:
    • VoiceEngine:音频引擎层,主要完成编解码(Codec)、网络抖动缓冲区(NetEQ)、3A(降噪/回音消除/自动增益);
    • VideoEngine:视频引擎层,主要完成编解码(Codec)、网络抖动缓冲区(jitter buffer)、图像增强;
    • Transport:网络模块,主要完成加解密(SRTP)、多路复用(音视频用同一个管道收发)、P2P(主要是NAT穿越相关);
  • 设备层:
    • Audio Capture/Render:音频的采集、渲染(播放)功能;
    • Video Capture:视频采集模块;
    • Network I/O:搞一些网络发送,TCP/UDP这种;

三、数据流转：

• 主要分为发送侧和接收侧，发送侧和接收侧还会有很多联系，那么就在中间那一块；

  • 发送侧：

    • 音频本地采集->进行音频编码->打包成RTP/RTCP包->进行平滑处理->通过网络发送出去;

    • 视频本地采集->一路进行本地渲染，一路进行编码->打包RTP/RTCP包->平滑处理->网络发送;

  • 接收侧：
    从网络接收数据包->按照类型解析成RTCP/RTP，然后按照音视频分别处理；

    • RTP数据包：
      • 视频：放入jitterbuffer中->进行视频解码->视频渲染；
      • 音频：放入NetEQ中（音频解码->播放音频）；
      • 进行音视频同步；

  • RTCP数据包：

    • 流控模块：流控模块又有很多功能，比如带宽预测、丢包重传、纠错等等；

    • 带宽预测：

      • 基于丢包；
      • 基于延迟：REMB、TCC；

    • 反作用编码模块和平滑发送模块，比如预测出来的带宽是1M，但是目前数据已经达到2M：

      • 那么就要进行降低码率、分辨率等措施降低数据本身大小；
      • 平滑模块也要降低发送数据的频率；

    • 回音消除：

      • 将音频数据放入缓冲区，由采集端进行回音消除；

四、总结:

WebRTC早期作为一个VOIP公司的软件,被谷歌收购了之后(金额令人眼馋!!!)加入了一些强大的编解码器什么的,最终形成了一个强大的解决方案,并且已经加入了W3C推荐标准中.为啥这么做呢?原因很简单:谷歌内心寻思着:我已经都帮你想好了,调好了,总之就是做好了,还特别稳定高效,你直接调用JS的api就行了(即使您是即使半天只能憋出一个hello world的水平也是可以调用的).专业术语来说就是:不要重复造轮子!!!

玩归玩闹归闹,这种架构思路还是值得我们学习的:

• 优秀的接口封装:上层调用API的用户"傻瓜式"调用,这也是最好的接口设计,越简单越好;
• 平台无关性:底层设备相关层又做了一层薄薄的差异化封装,这样可以保证核心层真正做到了"设备无关";
• 高内聚,低耦合:引擎层音频\视频\网络又隔离地很彻底.可以应对:只有视频\只有音频\音视频同时具备等场景,妙哉!!!
• 其实还有很多很多优点,以后进一步分享给大家;

憋坏我了,以后文章的总结环节就是本人发泄\发牢骚\吐槽环节,没啥东西可以跳过!!!