HOSTEN的博客

本篇是一个bug的记录，原自一次需求对mediasoup worker层的修改需要引入一个自己的库，但是只有so库，找不到源码无法使用静态库的方式通过修改.gyp连接到worker中;对于.gyp中so库的引入网上很难找到对应的文档，所以按照ld连接库的方式添加；

WebRTC在弱网环境下传输较大的视频数据，比如：屏幕共享数据；会偶发的出现黑屏的问题；也就是说当视频的码率比较大且视频的分辨率比较高的时候，有一定概率出现黑屏的问题；本文基于M76分支的代码分析其WebRTC组包的两个关键函数；WebRTC的组帧逻辑主要在类中(在modules/video_coding/packet_buffer.cc中)，其中的和是组包的两个关键函数；这篇文章会分析其中的主要逻辑及可能导致问题的位置；

前面的文章都有提过WebRTC使用的加密方式是SRTP这个库提供的，这个三方库这里就不做介绍，主要是对rtp包进行加密；自然的其调用也是WebRTC的rtp相关模块；同时在WebRTC里也提供一个自定义加密的接口，本文将围绕这个接口做介绍及分析；

从命令行错误看，出错是因为，好吧，那就试着重新编译安装：安装这个很简单照着执行命令就行：安装完后，执行命令，输出如下图：说明安装成功了；；但是。。。问题还是没解决，接着在https://groups.google.com/g/discuss-webrtc/c/xXkmEzzpG_8/m/d1jiHe9HKwAJ谷歌论坛上找到类似问题：接着尝试：；在执行了brew unlink libtool后，继续尝试编译，，顺利编译完成；不行其实，然后看执行命令中有个错误：也就是说默认使用libtool不对

关于createAnswer的流程在前面的文章这篇文章中有详细的分析。

最近项目中发现远端的视频调用track的set_enabled设置成false后，视频画面是黑屏；通过断点分析，发现gl部分还是有视频帧，并且在渲染；这篇文章就是set_enabled这个接口开始，详细分析其中调用流程；本文会详细的分析这个接口的调用流程；

基于rfc2198规定的格式，介绍最新版WebRTC中的音频red及如果添加到老版本支持

RedFEC (Reduced-Complexity Forward Error Correction) 是一种前向纠错协议，定义在RFC2189中，它旨在通过向数据流中添加冗余信息来提高数据传输的可靠性；RedFEC通过在发送端对数据进行冗余编码，并在接收端使用冗余数据进行纠错来抵抗数据包丢失或错误。在规范中即定义了打包的格式，及如何通过RedFEC生成冗余包来对原始数据进行保护；异或的规则：两个值不相等则为 1，相等则为 0；当两个输入位相同时，异或结果为0。

要使用RED，更改编解码器的顺序，使它在Opus编解码器之前。当你在相对较小的50kbps的Opus流旁边发送几百千比特的视频时，基于拥塞的Opus音频的FEC策略没有太多意义。在重度数据包丢失的情况下，LBRR使用的比特率最高可达10kbps（或数据速率的三分之二）。SILK的LBRR，也就是低比特率冗余，也包含在Opus中（记住Opus是一个混合编解码器，它在比特率谱的低端使用SILK）。然而，Opus中的SILK与Skype早年开源的原始SILK相当不同，用于前向错误纠正模式的LBRR部分也是如此。

Opus 编码器的 OPUS_SET_COMPLEXITY 参数控制编码器的复杂性，这个参数的范围在 0 到 10 之间，其中 0 是最低复杂性，10 是最高复杂性。调整 OPUS_SET_COMPLEXITY 参数会影响编码器的以下行为：计算复杂性：将 OPUS_SET_COMPLEXITY 参数调高会增加编码过程的计算复杂性。这意味着，更高的复杂性可能会导致更高的 CPU 利用率和更大的延迟。

音频对流的实时性要求比较高，对流的连续性要求也有较高要求，本文从带宽分配和发包的优先级两方面，分析WebRTC中的是怎么处理音频的；

GPUImage使用OpenGL提供了很多的图像处理算法，包括最常用的美颜处理、水印等功能，这些基本的功能如何添加到WebRTC中，本文以美颜为例子，叙述主要的改造流程；同时也适用于OpenGL等图像处理库；注：以下代码是使用WebRTCm76中的iOS端做分析，其他端处理思路类似。

下图是通过AECDump获取的数据：上图中红框 中input(麦克风采集的数据) 和 reverse(播放的数据)中相似，所以经过算法后被消除；需要注意的是AEC3算法是没有默认起始值，也就是说开始阶段算法处于学习阶段；对于AEC3的原理网上有很多的介绍文章，推荐一篇WEBRTC AEC3算法原理这里大致总结，可以分为以下几个步骤：通过预测算法计算回声信号的延迟和增益，即预测滤波器。预测滤波器使用参考信号（如发话人的声音）与扬声器输出信号的相关性进行计算，并预测出回声信号。

在文章介绍了抖动消除的基本概念，以及在WebRTC中的实现等；这篇文章降围绕NetEqImpl，展开源码分析，本文不会分析具体算法，主要是看起核心处理逻辑；

NetEQ是WebRTC音频子系统中的一个重要组件，它的全称是Network-Adaptive Digital Audio Playout Queue（网络自适应数字音频播放队列）；在术语表里的解释是：一种动态抖动缓冲区和错误隐藏（丢包补偿）算法，用于去除网络抖动和数据包丢失的负面影响。在保持最高语音质量的同时，保持尽可能低的延迟。在WebRTC应用程序中，音频数据包会被存储在抖动缓冲区中，以平滑处理由于网络延迟和抖动引起的数据包到达时间的变化。

在文章在调用直方图获取到index作为level后，接着会调用去判断有没有峰值，如果有就需要处理；本文是音频延时处理的第三篇，也是对计算音频延时level的最后计算结果；DelayPeakDetector类的主要功能是计算并记录连续延迟值的最大值，并提供方法来重置延迟峰值并查询当前的最大延迟值。该类还提供了一个阈值，用于确定何时应将延迟值归零；

他们的作用依次介绍如下：buckets_，直方图中桶的概念，也就是直方图中一个一个的条形图；在这个类中每一个桶，表示这一项(x轴)的概率值,使用Q30标识(也就是数组索引对应的个数的延迟的百分比)，所有桶元素之和不大于1；例如：buckets_[1]=0.14 也就是14%，表示一个单位延迟的包对应的占比是14%；buckets_[2]=0.82 也就是82%, 表示两个单位延迟的包对应的占比是82%；buckets_[3]=0.04 也就是4%, 表示两个单位延迟的包对应的占比是4%；

/ 是不是收到的第一个包 bool first_packet_received_;// 数据包缓冲区的容量 const size_t max_packets_in_buffer_;// histogram 也就是直方图 std :: unique_ptr < Histogram > histogram_;// 直方图分位数 const int histogram_quantile_;// 直方图的模式 const HistogramMode histogram_mode_;

在WebRTC中混音一般是主要用在将多个远端的音频流混合成一路用于播放，也就是主要在获取播放数据的时候使用，在WebRTC中最主要的实现是和这两个类，其中AudioMixerImpl用于混音前数据获取和处理，FrameCombiner主要是混音和混音后的数据处理；接下来的源码分析主要基于这两个类及接口函数的调用流程分析其源码实现，本文在牵扯具体算法的地方使用调试等方式进行分析；

这篇文章主要介绍WebRTC中一些音频工具这些，大部分都在目录下，这个文件夹下提供音频的大量算法，包括sinc重采样算法，音频数据格式的转换:例如 float转int16_t格式等方法；同时也提供了WavFile类用于实现对wav文件的读写，使用这个类可以便捷的将pcm写入到文件中，同时也能方便读取wav文件；如果篇幅足够这里也会介绍混音的相关实现，这部分在之前的文章其实有介绍，这里将会详细分析其源码实现；

在前面的一系列文章中介绍了stun协议相关的内容，在介绍获取candidate的文章中都有涉及到对发送stun消息的构造，对服务返回消息的解析等逻辑；本文主要的内容就是介绍WebRTC对stun消息封装，看源码中是如何构建和解析stun的相关消息；这其中也会设计到对于ipv6和ipv4的地址封装类和IPAddress的介绍；

分析或阅读过WebRTC源码的都知道，在源码中有很多的类似RTC_CHECK、RTC_CHECK_EQ、RTC_DCHECK_EQ等类似的检测函数，这些检测函数都是在源码的rtc_base目录下的。可以看到这个函数中先使用RTC_DCHECK去检查这时候数据是否合法，如果都是true就继续执行，类似的调用还有RTC_CHECK_LE，也就是检查。这个文件的.h文件中定义有很多的宏，从简介我们也知道主要的参数检查也都是使用宏，这里的源码分析也就从宏展开的过程看源码 ，

文章介绍的这两个类都是在rtc_base目录下的，这个目录下的都是一些WebRTC中使用基础类，比如：check.cc使用最多的类似断言检查的工具类，network.cc 也就是管理网络相关的；对于WebRTC提供的这个工具，将其代码分离做了一个mac下的控制台demo，并写了一写测试代码，一节stun消息的模拟解析；地址如下：https://github.com/hosten1/WebRTC_Buffer 欢迎小星星。

在上一篇文章中分析了接收到nack后解析的主要流程。在WebRTC里NACKRTXRTX协议是一种针对实时音视频通信的传输协议。RTX协议主要解决了丢包问题，以提高实时音视频通信的质量。RTX协议的详细规定可以在以下的文档中找到，该文档规定了RTX协议的用于视频数据的具体实现方式；需要注意的是，以上文档仅规定了RTX协议在视频数据中的应用，RTX协议在音频数据中的应用并未在此列举。但是，RTX协议的原理与应用是相通的，因此在音频数据中的应用方式与在视频数据中类似。

在文章 WebRTC系列-Qos系列之RTP/RTCP源码分析-RTP/RTCP包解析-3的2.3.3章节介绍了NACK包在WebRTC中解析方式及RFC规定协议的定义。这篇文章开始，详细分析其接受RTCP包到解析nack的处理流程；

在之前的文章介绍了音频开启对包重传的方式及验证是否开启的成功的方式；在文章的2.3.3章节介绍了NACK包在WebRTC中解析方式及RFC规定协议的定义。在WebRTC中是支持音频和视频的NACK，本文只分析NACK及其重点相关的机制，不分析jitterbuffer或者neteq的相关知识及实现，这些将会有其他的文章重点介绍。

在前面的文章和中分别介绍了RTP及RTCP协议，最后通过抓包的方式直观的了解的包的组成；这一篇文章，根据前面对WebRTC的了解基础上，进行WebRTC源码分析，看WebRTC是怎样实现这些协议及处理流程得；本文的源码分析基于WebRTC m76分支；

本文是接文章继续分析RTCP的SDES、Compound RTCP在WebRTC的使用；

上一篇文章介绍了RTP协议，通常RTP负责传输数据，RTCP一起工作，RTCP负责对RTP的通信和会话进行控制（如流量控制、拥塞控制、会话源管理等）；同rtp协议一样，协议由 IETF（http://www.ietf.org/）定义在和3551中；

在目前的WebRTC各个版本中音频的重传目前都是默认处于关闭的，也就是音频的sdp里默认是没有NACK；Feedback的subtype是205就是nack的的rtcp包；

rtp在RFC3550前12个8Byte(96-bit)存在于每个 RTP 数据包中，而CSRC部分只有Mixer发送的报文才会有。这些字段含义如下：版本 (V)：2 位version默认都是2，这个字段表示当前使用的 RTP 的版本。（值 1 由 RTP 的第一个草案版本使用，值 0 由最初在“vat”音频工具中实现的协议使用。）填充（P）：1位表示当前这个包是不是有RTP填充的数据，如果p=1表示有填充数据，p=0表示没有填充；

在前面的文章视频的采集流程中，视频数据采集完成后到编码器之前，如果需要渲染处理那里需要两路视频，WebRTC是实现了一个视频分发器VideoBroadcaster；用来分发采集的视频帧；这篇文章主要以iOS为例介绍VideoBroadcaster分发视频流的过程，需要强调的是iOS的本地渲染没有使用VideoBroadcaster，而是直接通过系统提供的预览类直接显示；Android和pc端的实现都是经过流转数据后显示；

上一篇介绍了adm及其相关的模块；这篇文章主要介绍WebRTC中对于adm采集播放的接口及一些相关的控制接口；其中的在WebRTC中是的作用是各个平台具体。

在前面的文章中介绍了视频编码器参数的设置方法；同样的对于音频也可以设置编码的参数，首先说一下对于音频并没有提供设置很多参数的接口，能设置有maxBitrate；在了解其参数的处理流程后，也可以自己加一些编码器的参数设置；在上面的文章中介绍了RTPSender和，及这个两个的关系；音频这一层的关系和调用方式同音频类似；都是在调用（代码在sdk/objc/api/peerconnection/RTCRTPSender.mm中）后然交给RTCSenderBase及其他模块处理；

WebRTC中提供了对iOS和Android的adm相关接口的封装，其中iOS端的ADM主要类关系如下图：其中是WebRTC对外提供的adm统一接口类，定义了一些常用的接口，AudioDeviceModuleIOS继承这个类并实现其定义的方法，其他端的adm也都是实现这个接口；静态方法Create用于创建实例；RegisterAudioCallback 提供注册采集播放数据回调接口；Init 初始化音频播放/采集设备；启动/停止音频播放/采集设备；

( Voice Activity Detection),以及完成全部的处理后测量讲话的音频水平；中获取数据，这个方法会把每个音频源的数据添加到一个数组中，然后会排序。由于编码任务将在内部发布到每个流，因此需要复制(原注释翻译)；这一步之后，webrtc会判断下该帧数据需不需要。在ADM中音频录制数据从平台采集后最终都会在。,移动端主要实现两个接口，录制数据传递接口。,然后就是发送数据；

在文章中总述了音频的采集和播放流程，接下来将分几篇文章详细分析具体的实现以及，如果实现增加外部数据源；iOS端音频采集是使用，这篇文章不介绍，具体使用点击链接；

在上一篇文章中，介绍了从摄像头到中视频流的调用流程及其中对视频流的处理；这篇文章将介绍iOS端WebRTC对于H264编码器的封装，及视频流从到硬件编码编码返回编码后的帧到当前类的过程；

这篇是接收端带宽评估的最后一篇，在上一篇中分析了在接收端基于丢包的带宽估计处理方法；带宽估计后的值一方面会反馈到编码器控制编码码率，同时也会反馈到节拍器中；

在上一篇文章主要介绍了接收端带宽估计在接收端根据延迟估计评估发送端的带宽然后通过RTCP发送的过程；这一篇主要介绍WebRTC接收端带宽估计的发送端处理；