目录结构说明
在本节中将介绍WebRTC的目录结构以及各个目录的作用
通过阅读本节将会在未来需要修改源代码时为你提供帮助外层目录结构
1.api
接口层，外部通过调用本层来使用WebRTC的核心功能
2.call
管理层，通过本层可以对数据流进行管理
3.video
视频相关的逻辑，包括处理、编解码等
WebRTC入门（三）---- 目录结构
2021-07-03 16:40:51WebRTC之带宽控制部分学习(1) ------基本demo的介绍
2021-07-03 16:40:04WebRTC的代码真是非常之大啊，下载以及编译了我好几天才搞完。。。。。
可以看到WebRTCd代码分成了4个部分，目前为止只看了talk里的一些东西。
1、 talk中的项目文件大多数都是以libjingle开头的，可以看出libjingle是WebRTC中非常核心的一个东西啦。
libjingle中开辟了两个通道，分别为会话通道和数据通道，一个用来会话建立管理等，一个用来传输数据。
libjingle_media是用来渲染获取视频，libjingle_p2p和libjingle_peerconnection是不同的会话方式用到的库吧，现在还没有细看
peerconnection_client和peerconnection_server则是可以直接运行的demo，设为启动项目就可以测试了，先运行server。
2、由于项目研究的是关于带宽估计的东西，所以我们看的文件主要有两个，一个是上行带宽的估计和控制，一个是下行带宽的估计和控制
上行带宽的文件在webrtc/modules/bitrate_controller，下行带宽的文件是remote_bitrate_estimator
下面讲一讲Goolge的WebRTC中自带的码率控制：
webrtc视频流程
2021-07-03 16:39:301. 创建视频引擎VideoEngine
函数：VideoEngine::Create()
构建VideoEngineImpl对象，该类继承了ViEBaseImpl、ViECodecImpl、ViECaptureImpl、
ViEFileImpl、ViEImageProcessImpl、ViENetworkImpl、ViERenderImpl、
ViERTP_RTCPImpl、ViEExternalCodecImpl、VideoEngine类，
同时ViEBaseImpl实例化视频共享数据单元ViEShareData，将该共享数据对象分发给各Impl类。webrtc nack实现原理
2021-06-28 23:40:161.nack 简介
webrtc 中nack是最基本的QOS策略，与ack机制不同的地方是nack是接收端检测到丢包时，告知发送端具体丢包的序号，接收端收到nack后从缓存中找到对应的包并发送出去。
2. nack实现
nack rtcp报文格式如上图所示，pt=205。Packet identifier(PID) 为丢包起始参考值，Bitmap of Lost Packets(BLP)为16位的bitmap，对应为1的为表示丢包数据，具体如下抓包分析：
webrtc QOS方法一（NACK实现）
2021-06-28 23:32:11一、概念
与NACK对应的是ACK，ACK是到达通知技术。以TCP为例，他可靠因为接收方在收到数据后会给发送方返回一个“已收到数据”的消息（ACK），告诉发送方“我已经收到了”，确保消息的可靠。
NACK也是一种通知技术，只是触发通知的条件刚好的ACK相反，在未收到消息时，通知发送方“我未收到消息”，即通知未达。
在rfc4585协议中定义可重传未到达数据的类型有二种：
1）RTPFB：rtp报文丢失重传。
2）PSFB：指定净荷重传，指定净荷重传里面又分如下三种：
1、PLI (Picture Loss Indication) 视频帧丢失重传。
2、SLI (Slice Loss Indication) slice丢失重转。
3、RPSI (Reference Picture Selection Indication)参考帧丢失重传。
在创建视频连接的SDP协议里面，会协商以上述哪种类型进行NACK重转。以webrtc为例，会协商两种NACK，一个rtp报文丢包重传的nack（nack后面不带参数，默认RTPFB）、PLI 视频帧丢失重传的nack。
webrtc源码之nack&&rtx详解
2021-06-28 23:30:30video协商为h264(payload type=96)
从sdp可得到：
1）profile-level-id=42001f
Profile: 66(hex: 42)
Level: 3.1(hex:1f)转成十进制，再除以10
2）packetization-mode=1
表示I帧会拆分成多个rtp包发送，对于264来说，rtppayload的第一个字节（0x7C）的低5bit为(11100)，十进制为28，代表此nalutype为FU-A，多包封装类型。
3）RTP/AVPF
AVPF中的F表示支持RTCP的传输层保护，S表示安全保护（SRTP）
4) a=fmtp:97 apt=96
表示96类型的rtp包的重传包采用97的payloadtype的rtx包保护，rtx包的rtp header中的sequence num与rtp不一致，但timestamp一致。
Rtx包的payload的前两个字节为原重传rtp包的rtp sequencenum
2、webrtcpeerconnection_client项目修改项
webrtc的rtp重传代码分析
2021-06-28 23:29:13pgm不太能用，没有想象中的可靠，重传机制貌似仍然使用组播重传，丢包率80%的网络感觉没啥改进，如果有所好转延迟估计也是个不小的问题。
后听说rtp也有nack机制，webrtc基于rtp实现了重传在一定程度上保证可靠性。
在各路大神的指引下找到了rfc4585，看到了这么一段 RTCP扩展反馈报文，有一种nack报文 
webrtc QOS方法一（NACK实现）
2021-06-28 09:41:48与NACK对应的是ACK，ACK是到达通知技术。以TCP为例，他可靠因为接收方在收到数据后会给发送方返回一个“已收到数据”的消息（ACK），告诉发送方“我已经收到了”，确保消息的可靠。
NACK也是一种通知技术，只是触发通知的条件刚好的ACK相反，在未收到消息时，通知发送方“我未收到消息”，即通知未达。
在rfc4585协议中定义可重传未到达数据的类型有二种：
1）RTPFB：rtp报文丢失重传。
2）PSFB：指定净荷重传，指定净荷重传里面又分如下三种：
1、PLI (Picture Loss Indication) 视频帧丢失重传。
2、SLI (Slice Loss Indication) slice丢失重转。
3、RPSI (Reference Picture Selection Indication)参考帧丢失重传。
在创建视频连接的SDP协议里面，会协商以上述哪种类型进行NACK重转。以webrtc为例，会协商两种NACK，一个rtp报文丢包重传的nack（nack后面不带参数，默认RTPFB）、PLI 视频帧丢失重传的nack。
WebRTC基于TransportCC和Trendline Filter的发送端码率估计(Sendside-BWE)
2021-06-28 09:41:16众所周知，WebRTC的拥塞控制和码率估计算法采用GCC算法[1]。该算法充分考虑了网络丢包和网络延迟对码率估计的不同影响，分别基于丢包率和网络延迟进行码率估计，最后综合这另种码率得出最优值。在算法实现上，基于丢包率的码率估计在发送端进行，基于网络延迟的码率估计在接收端进行。最后在发送端计算出最优值，作用于Codec和PacedSender模块。GCC算法能够较好地基于网络实时状况估计网络带宽，为网络实时通信应用打下坚实基础[2][3][4]。
然而，随着时间推移，在实际测试中发现GCC算法逐渐显出一些弊端，比如不能适应所有网络模型，应对网络峰值能力差，等等。为此，Google官方从M55版本引进最新的拥塞控制算法Sendside-BWE，把所有码率计算模块都移到发送端进行，并采用全新的Trendline滤波器取代之前的Kalman滤波器[5]。实测表明，新的算法实现能够更好更快地进行码率估计和网络过载恢复。
本文基于WebRTC的M66版本和相关RFC，深度分析学习最新Sendside-BWE算法的实现。
WebRTC中丢包重传NACK实现分析
2021-06-28 09:40:29在WebRTC中，前向纠错(FEC)和丢包重传(NACK)是抵抗网络错误的重要手段。FEC在发送端将数据包添加冗余纠错码，纠错码连同数据包一起发送到接收端；接收端根据纠错码对数据进行检查和纠正。RFC5109[1]定义FEC数据包的格式。NACK则在接收端检测到数据丢包后，发送NACK报文到发送端；发送端根据NACK报文中的序列号，在发送缓冲区找到对应的数据包，重新发送到接收端。NACK需要发送端发送缓冲区的支持，RFC5104[2]定义NACK数据包的格式。</br>
本文在研究WebRTC源代码的基础上，以Video数据包的发送和接收为例，深入分析ANCK丢包重传机制的实现。主要内容包括：SDP协商NACK，接收端丢包判定，NACK报文构造、发送、接收和解析，RTP数据包重传。下面分别详细论述之。</br>