1、视频编码格式初始配置
media\engine\internaldecoderfactory.cc
2、FEC
Branch65版本 src\modules\rtp_rtcp\source\forward_error_correction.cc
对抗网络丢包：前向纠错(FEC)
FEC头部为10字节，包含内容如下：
E flag：扩展位，供将来使用，当前设置为0。
L flag：指示长偏移掩码是否使用，0表示偏移掩码为16位，1表示为48位。
P/X/CC/M/PT recovery field：由本FEC包所保护的所有媒体数据包的RTP头部的P/X/CC/M/PT flag位经XOR操作后得到。
SN base：本FEC包所保护的媒体数据包的RTP报文的序列号最小值。
TS recovery field: 由本FEC包所保护的所有媒体数据包的RTP头部中的Timestamp字段经XOR操作后得到。
Length recovery field: 由本FEC包所保护的所有媒体数据包的负载长度(包括CSRC、RTP头部扩展、负载和padding的长度之和，以16位无符号网络序表示)经XOR操作后得到。
原理：
3、视频分辨率初始配置
pc\videocapturertracksource.cc、
选取的原则是，在kVideoFormats里面找参数与kDefaultFormat默认值最接近的一组参数，作为本端的编码能力。
4、视频码率
media\engine\webrtcmediaengine.cc
调用 EncoderStreamFactory::CreateEncoderStreams
BPP指数：每像素位数（BPP）是应用于视频文件中每个像素的平均数据量。通过将数据速率（kbps）除以视频的每秒像素数（像素宽度乘以高度像素乘以每秒帧数）来计算：
BPP = 数据速率/（分辨率*每秒帧数）
BPP通常在0.05到0.150之间，具体取决于场景中的运动量。运动越多，BPP应该越高。
BPP也与分辨率成反比：分辨率越低，在不产生巨大比特率的情况下BPP越高。这是因为与高分辨率视频相比，低分辨率视频中要复制或参考的总像素更少。
要基于BPP计算比特率的大小，
比特率 =（分辨率*每秒帧* BPP）/ 1000
一般bpp=0.11适合大部分编码器和编码标准，可达到比较好的视频效果
5、帧率最大值
理论上编码器的输入帧率小于等于视频采集的帧率。编码器编码的性能+视频采集帧率决定编码器的输入帧率。
若摄像头的640*480的采集帧率是30fps，若编码器的640*480的编码性能是60fps，那么编码器的输入帧率为640*480 30fps。
若编码器性能比较差，640*480的编码性能是25fps，那么编码器的输入帧率为640*480 25fps。
实现这个最低帧率选择的算法是FrameDropper漏斗算法。算法大概原理是，漏斗进口定时将视频采集的帧率送到漏斗队列里面，当编码器性能调度过来，找算法要数据的时候，将漏斗的最新一帧视频送给编码器。
详细实现参见：VideoStreamEncoder::EncodeTask->Run->OnIncomingFrame
代码：
Branch 65:
webrtc\media\engine\webrtcvideoengine.h
6、SRTP
webrtc\src\webrtc\api\peerconnectioninterface.h
disable_encryption = true 取消SRTP
disable_encryption = false 开启SRTP
配置秘钥 就是 控制dtls的接口
7、上述帧率码率流程
在webrtc里面函数实现如下：
->VideoStreamEncoder::EncodeVideoFrame
->VideoSender::AddVideoFrame----在这个函数中读取全局变量encoder_params_，判断是否需要调整视频参数。
->VideoSender::SetEncoderParameters
->VCMGenericEncoder::SetEncoderParameters
8、mtu最大包长
用RTP/RTCP实现是实时视频数据的传输，要控制数据包的大小，使之不被路由器分片，webrtc默认设置
Branch65 代码位置 \src\media\engine\constants.cc
9、BWE降码率
BWE模块决定视频通讯中可以发送多大码率视频不会使网络拥塞，防止视频通讯质量下降。
最新版本webrtc使用trendline算法实现网络拥塞预估，早期版本使用KalmanFilter算法。两种算法都是基于接收端的网络延迟进行码率估计。早期的KalmanFilter算法是在接收端根据网络延时，计算出合适的带宽，通过REMB RTCP报文反馈给发送端，让发送端按照该码率发送视频数据。trendline算法对此进行了优化，在发送端根据网络延时，计算合适的带宽。
基本思想是：丢包率反映网络拥塞状况。如果丢包率很小或者为0，说明网络状况良好，在不超过预设最大码率的情况下，可以增大发送端码率；反之如果丢包率变大，说明网络状况变差，此时应减少发送端码率。在其它情况下，发送端码率保持不变。
基于延迟的拥塞控制是通过每组包的到达时间的延迟差(delta delay)的增长趋势来判断网络是否过载，如果过载进行码率下调，如果处于平衡范围维持当前码率，如果是网络承载不饱满进行码率上调。这里有几个关键技术：包组延迟评估（InterArrival）、滤波器趋势判断（TrendlineEstimator）、过载检测（OveruseDetector）和码率调节（AimdRateControl）。
webrtc具体实现：
丢包拥塞控制（trendline）
BaseChannel::ProcessPacket
->WebRtcVideoChannel::OnRtcpReceived
->Call::DeliverPacket
->Call::DeliverRtcp
->VideoSendStream::DeliverRtcp
->VideoSendStreamImpl::DeliverRtcp
->ModuleRtpRtcpImpl::IncomingRtcpPacket
->RTCPReceiver::IncomingPacket
->RTCPReceiver::TriggerCallbacksFromRtcpPacket
->SendSideCongestionController::OnTransportFeedback
基于延时拥塞控制
BaseChannel::ProcessPacket
->WebRtcVideoChannel::OnRtcpReceived
->Call::DeliverPacket
->Call::DeliverRtcp
->VideoSendStream::DeliverRtcp
->VideoSendStreamImpl::DeliverRtcp
->ModuleRtpRtcpImpl::IncomingRtcpPacket
->RTCPReceiver::IncomingPacket
->RTCPReceiver::TriggerCallbacksFromRtcpPacket
->BitrateControllerImpl::RtcpBandwidthObserverImpl::OnReceivedRtcpReceiverReport
->BitrateControllerImpl::OnReceivedRtcpReceiverReport
->SendSideBandwidthEstimation::UpdateReceiverBlock
->SendSideBandwidthEstimation::UpdateEstimate
10、nack
webrtc支持RTPFB和PLI FB两种重传方式。
\src\media\engine\webrtcvideoengine.cc
视频重传：VideoSendStreamImpl::ConfigureProtection
音频重传：VCMLossProtectionLogic::SetMethod
11、视频PT
也就是RTP包头的PT值 有效荷载类型，占7位，用于说明RTP报文中有效载荷的类型，如GSM音频、JPEM图像等,在流媒体中大部分是用来区分音频流和视频流的，这样便于客户端进行解析
src\media\engine\webrtcvideoengine.cc
12、音频PT
\src\media\engine\webrtcvoiceengine.cc
13、ICE的参数配置
全局搜索RTCConfiguration类的实现
Branch65 在api\peerconnectioninterface.h
something from :
https://blog.csdn.net/CrystalShaw/article/details/83413772
https://blog.csdn.net/CrystalShaw/article/details/80372015
https://blog.csdn.net/qq_37051858/article/details/111353756
丢包检测算法：https://blog.csdn.net/tanningzhong/article/details/87278810