Ziwubiancheng的博客

webrtc当中有几个比较相似的类，看着都是发送RTP数据包的，分别是：和还有以及，这说明什么呢？首先，说明我会很多连词（🤬），元规正传（🤬），其次，说明他们都很像，容易给我们搞晕，最后，我们需要搞明白，这几个类各自扮演什么角色，设计意图是什么呢？如果是你设计，你怎么设计，整一个万能类不就行了，反正就是发送RTP数据？行不行，你说！小的不才，有点感悟记录下来，行不行您自己看！主要代码核心作用 是 WebRTC 代码中发送端专用的 RTP 包对象，承载了要发送的 RTP 包及其元数据。它继承自 ，不

那么，为什么要这么多Channel，只写一个叫做SuperChannel行不行（很多程序猿同胞都这么干，大而全，吃一个就饱了）？？肯定是可以实现功能了，不过没有架构设计思想，以后扩展会很麻烦，并且会有很多重复代码。

是外部接口，将传入的 RTP 包封装后调用内部函数处理。是内部核心逻辑，负责：将 RTP 包按优先级和时间戳入队列；管理动态发送预算；更新流量探测器。Pacer 的最终目标是控制 RTP 包的发送节奏，确保带宽利用率的同时避免网络过载，同时按优先级调度多种类型的数据包。

public:// 用于设置目标码率// 用于计算我们这个时间分片，有多少数据可以发送private:// 通过带宽评估算法评估出的目标码率（也就是1s内发送多少数据）// 在budget中最大可以存放多少字节// 在一个时间分片内，还有多少数据可以发送本文主要介绍了Pacer模块中怎么根据目标码率，然后通过来完成动态调整每段时间的字节预算，使整体码率稳定在设计的目标值附近，同时平衡欠载和过载的情况。

每个流由Stream类表示，Stream当前队列状态，如总字节数、包大小和优先级。内部维护单独的优先级队列（调度时实时更新优先级，确保新加入高优先级包时能调整队列次序。是一个高效的多流、多优先级调度队列，适用于 RTP 媒体数据的分组发送场景。它通过流内、流间的双重调度机制，结合优先级动态提升、统计队列时间和暂停控制等特性，确保在带宽有限的网络环境中最大程度提高数据的实时性和发送效率，是 WebRTC Pacer 模块的核心部分。

本文主要介绍了Pacer模块的作用，以及相关重要的框架代码，其实还有很多细节后面再打开看看。

函数是 WebRTC 中 RTP 协议层实现丢包恢复的重要部分。它利用记录和 RTX 协议实现高效的重传机制，同时考虑到带宽管理、速率限制和两种重传策略（RTX 和普通 RTP）的兼容性。在具体代码实现中，它通过灵活的封装和严格的速率控制，保证了无损恢复的同时避免了网络拥塞情况。

本文主要介绍了接收Nack包的流程，其实也就是接收一般RTCP包的流程，并且从Call模块开始走读了一下代码，走读代码过程中千万要记住自己大概处于流程的什么位置，要么会lost yourself！！！

我的是Windows11平台，在要下载代码的目录打开cmd，记住，不要使用powershell，由于depot_tools某些脚本设置，会有其他问题。备注：7897是你自己代理的端口。

上一篇文章我们记录了丢包，但是这些包都是一些可疑丢包，本文我们就分析下如何从可疑丢包中找到真正丢包。本文主要介绍了从可疑丢包中找到真正丢包的逻辑，我们也看出来，webrtc不是简单的丢了包就要求重传，还对序列号跨度，超时时间等做了限制，这样才不会导致重传风暴。

本文主要介绍了NACK的格式，以及NACK的调用栈，并且介绍了如何判断丢包，但请记住，这些包都是“可疑丢包”，真正的丢包下一节介绍。

NACK（Negative Acknowledgments）是一种反馈机制，用于通知发送端某些数据包在传输过程中丢失了，从而让发送端可以知道需要重新发送丢失的数据包。RTX（Retransmission）是WebRTC中实现NACK的一个实际重传机制，用于基于NACK反馈进行丢包的重传。

RTCP（RTP Control Protocol）是一种控制协议，与RTP（Real-time Transport Protocol）一起用于实时通信中的控制和反馈。RTCP负责监控和调节实时媒体流。通过不断交换RTCP信息，WebRTC应用能够调整比特率、编码方式等，适应网络条件，确保音视频通话的质量。同时，RTCP与RTP共同工作，使得数据传输不仅准确，而且高效。

本文主要介绍了RTP协议，要理解它只是传输音视频数据，不管你丢包，质量，带宽等乱七八糟的东西，这些都是由RTCP配合完成的，下一节看看RTCP。

WebRTC 的 QoS 策略是一个复杂的多层动态优化过程，以实现实时音视频通信的高质量和低延迟。提高网络可靠性（NACK/RTX、FEC、JitterBuffer 等）。动态调整码率与带宽适配（拥塞控制、Transport-cc、主动丢包等）。降低数据发送量（SVC、Simulcast、动态帧率调整等）。延迟优化（Pacer、DTLS 优化、ICE 节点选择等）。音频质量优化（Opus 自适应、音频冗余编码、回声消除等）。设备性能适配（硬件加速、帧率和分辨率平衡等）。

前面介绍了视频数据采集，那么采集到的数据如何上传给上层应用的？本节看看。其实逻辑还是非常明确的，也是常见的设计模式（观察者模式）。将底层数据一层层抛给应用层，注意要关注，处理媒体数据，由于量非常大，尤其高清视频，我们所说的抛数据不是你一层层拷贝，留意每个环节怎么做的，哪些环节拷贝了数据，因为什么迫不得已拷贝的，这对诸位写出软件实时性有很大影响。！！

本节主要讲了怎么将两个Filter进行连接，连接之后就可以进行数据采集了。

是DirectShow API中的一个函数，它用于创建一个枚举器对象，该对象可用于枚举系统中注册的所有DirectShow滤波器的类标识符（CLSID）。: 指定要枚举的设备类别的 CLSID。传入NULL时，将枚举所有的设备类别。: 指向接口指针的指针。枚举器将通过该指针返回。dwFlags: 可选的标志，用于指定枚举器的行为。

DirectShow是一种由微软开发的多媒体框架，主要用于Windows平台上处理和操控流媒体数据。该技术提供了一组API，支持音频和视频的捕获、处理、转换和播放。模块化结构DirectShow基于过滤器（filter）的架构，每个过滤器执行特定的任务，如源读取、数据解析、编码、解码、渲染等。过滤器之间通过引脚（pin）连接，形成一个可定制的处理链。多种格式支持支持多种媒体格式，包括AVI、MPEG、ASF、WAV、MP3等。这使得开发者可以构建能够处理多种媒体格式的应用程序。实时流媒体处理。

本章主要介绍了视频数据采集的关键类VcmCapture、VideoTrack、VideoBroadcaster，VideoCapture。并且交代了这几个类的主要职责，以及如何利用他们创建一条数据链路的。后续，对具体的引擎再做分析。

本文主要介绍了音频数据采集线程、编码线程如何配合完成音频数据从采集到编码发送的流程。涉及到引擎层的AudioState（包括其中的adm），以及ACM模块，还有Call模块，如果不了解这几个模块，可以看我的WebRTC音频 03 - 实时通信框架-CSDN博客。

在WebRTC音频代码阅读过程中，我们发现有很多关键的类比较抽象，搞不清楚会导致代码阅读一脸懵逼。比如PeerConnection、Call、AudioState、Channel、Stream，本文就尽力介绍下。

路径：rtc_base\ref_counted_object.hpublic:protected:构造函数重载该类提供了多个构造函数重载，以便使用不同数量的参数初始化对象。构造函数使用完美转发将参数传递给基类构造函数。AddRef 方法AddRef()方法用于增加引用计数。标记为const表示它不会修改对象的逻辑状态。Release 方法Release()方法减少引用计数，并在计数达到零时删除对象（表示这是最后一个引用）。它返回一个枚举值，表示释放操作后的状态。

前面介绍了音频设备管理，并且以windows平台为例子，介绍了ADM相关的类，以及必须用到的重要API，本文我们分析下，在一个音视频呼叫过程中，音频是如何参与其中的，都有哪些成员参与其中。本文主要是介绍了音频各个模块在整个呼叫过程中所处的角色，以及何时创建（创建时机）、创建的什么样（类图）；主要从总体分析，如果要具体到每个类，后续会根据业务场景再做分析，比如：采集过程中用到哪几个类，具体调用哪个函数等等，关注我，不迷路！

上一节讲了WebRtc如何去管理音频设备的，最终得出结论就是使用了ADM。但是ADM之下，Windows、Linux、mac又各不相同，这一节就分析下Windows平台是如何管理这些音频设备的。也就是分析下AudioDeviceWindowsCore这个类都干了啥！分析之前我们得先看下Core Audio，因为这是最新windows平台对音频设备控制的模块。我们AudioDeviceWindowsCore也主要是调用Core Audio的API和音频设备进行交互的。

Audio Device Module (ADM) 用来管理详情可以参考：https://chromium.googlesource.com/external/webrtc/+/master/modules/audio_device/g3doc/audio_device_module.mdwebrtc中队音频设备得管理都是通过ADM完成的，并且抽象出了统一的接口类AudioDeviceModule，使用者不用管是什么系统平台，直接调用统一的方法即可。

前面介绍的http和https服务器都是直接返回了一段字符串，我们真正服务器都是你输入网页要展现一些富媒体的文本给你看的，其实就是服务器发布了一些文件，你本地浏览器下载这些文件，使用本地的引擎解析展示出来。看到没，你上个网其实就是把别人电脑的文件传给你看，而已！里面的坑应该就是npm安装不动，你懂的！

前面搭建的http服务器就是学习用的，不太安全啦，这次我们直接大家个带s（Secure），话不多说，开整！

作用是：监听在本地的 8080 端口，任何访问该端口的请求都会返回一个包含 “Hello, I am a http server” 文本的响应。发现8080端口已经被监听了！

一句话总结：通过拿到SDP信息，然后分发给子层各自建立自己的类对象，再将音视频流水线启动起来。因为媒体协商会将WebRTC所有代码串起来，代码实在太多了，阅读时候一不小心就离开主干了，因此，好多子函数没有展开，大家顺着关键函数往下自己读吧！

媒体协商

这里面这个key有讲究，使用了TLS（线程局部变量）去管理，你可以理解成在系统底层为每个变量创建了一个键值对，存为全局变量，为了方便快速找到线程（这样容易理解了，但是并不严谨，想严谨请看https://zh.wikipedia.org/wiki/%E7%BA%BF%E7%A8%8B%E5%B1%80%E9%83%A8%E5%AD%98%E5%82%A8）；windows平台相关api如下：TlsAlloc：为Tls对象分配空间，并且返回对应index；

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