Lce的专栏

Opus是一种开源免费的音频编解码器，支持音乐和语音，具有低延时、带内FEC、DTX、PLC等特点，默认22.5ms延时，非常适用网络实时传输。。Opus协议收录于，使用SILK和CELT两种编码。

BWE（Bandwidth Estimation）可能是WebRTC视频引擎中最关键的模块了。BWE模块决定视频通讯中可以发送多大码率视频不会使网络拥塞，防止视频通讯质量下降。早期的带宽评估算法比较简单，大多是基于丢包来估计，基本的策略是逐步增加发送的数据量，直到检测到丢包为止。为了让发送端获悉网络上的丢包信息，可以使用标准的RTCP的RR来发送周期性的报告。现代的带宽评估算法则可以在网络链路发生丢包以前就监测到网络拥塞，它可以通过侦测数据包接收的时延来预测未来可能的拥塞。

目前总结出WebRTC用于提升QoS的方法有：NACK、FEC、SVC、JitterBuffer、IDR Request、Pacer、Sender Side BWE、Probe、VFR（动态帧率调整策略）、AVSync（音视频同步）、动态分辨率调整。

对于C++库来说是整个MediaSoup库中最核心的部分，包括了基本的一些管理，这些管理或者关系相对于JS来说要少一些，但最主要的是流的传输，首先对于WebRtc 要先进行数据加密再传到服务端之后要对这些数据进行解密操作。另外包括整个数据的安全，它的验证机制是由C++部分进行验证的，包括流的流转，数据的流转，带宽的评估，发生丢包之后的通知客户端进行重传等操作都是有C++部分完成这些工作。RtpPack的起作用为对rtp数据包的一个分析，如Rtp包中有包头，拓展头，数据，对于数据协议或者解析都是它的工作。

如下是 Web A和 Web B 互通前的ICE流程，首先是要获取Candiate，因为两个web端各自都不知道所在的网络拓扑，所以在获取Candiate时，必须拿到所有类型的地址，其中就有通过STUN，TURN服务器获取relay类型的地址。webrtc的提供音视频解决方案是针对P2P的场景，如果在实际的应用中直接通过P2P来互通，首先NAT穿越就很麻烦，如果NAT场景比较复杂，整个互通流程就会变长，直接的影响就是首屏会出来的慢。上图是web对通的基本流程，图中描述的是两个web进行点对点互通。...

m74。旧版的视频JitterBuffer实现在VCMJitterBuffer类中，目前已经不用，新版的JitterBuffer的功能被分散到多个模块中，主要包括：PacketBuffer：负责帧的完整性，保证组成帧的每个包序列号连续，并且有一个包标识帧的开始，有一个包标识帧的结束；RtpFrameReferenceFinder：负责给每个帧设置好参考帧，同时兼顾GOP内各帧的连续性；FrameBuffer：负责帧的连续性和可解码性，这里帧的连续性是指某帧的所有参考帧都已经收到，帧的可解码性是指某帧的所

WebRTC前世今生，在2010年google收购了GlobalIpSolutions公司，并在2011年将其开源。WebRTC主要是用于web浏览器的多媒体及时通讯技术，可以实现在没有其他中间媒介的情况下实现点对点通讯。本文主要目的是了解WebRTC的整体框架，为后续深入学习WebRTC框架打下基础。......

rtc技术

2.2，audio_device_utility_win(.cc/h)，公用方法的文件，只有简单的几个函数，可以不太深究；

对于不支持采集和播放 10 ms 音频数据的平台，在平台的 AudioDeviceModule 和 AudioDeviceBuffer 还会插入一个 FineAudioBuffer，用于将平台的音频数据格式转换为 10 ms 的 WebRTC 能处理的音频帧。（3）iOS除了提供的可开关的AGC以外，还有一个AGC会一直工作，对信号的level进行微调；因为WebRTC 的音频流水线只支持处理 10 ms 的数据，不同的操作系统平台提供了不同的采集和播放时长的音频数据，不同的采样率也会提供不同时长的数据。.

pulseaudio為一個audio service，如下图OSS sink表示输出音源部分，从PulseAudio要转到声音设备的介面。pactl命令可以修改伺服器的设置以及配置，但pactl命令仅限于局限的范围。若要完整的功能，就必須要回归到最基本的指令pacmd，通过pacmd指令才可以完全的控制PulseAudio的服务核心。pulseaudio服务软件架构，将来自各个不同的音源转到正确的窗口，针对不同的应用程式做音量的调整，接受多个音源的输入（source）或是输出（sink）。...

在媒体通道中WebRTC使用SRTP来进行数据的加解密，DTLS的作用仅仅是用来做密钥交换，RTP/RTCP的数据为了与历史设备兼容性的考虑，完全通过SRTP来实现。下图为WebRTC媒体通过建立过程的简单描述，可以看出DTLS在整个协商过程中与其他流程的时序关系。在Datachannel数据通道中，WebRTC完全使用DTLS来进行协商和加解密。MediaChannel媒体通道。Datachannel数据通道。WebRTC中DTLS参数。...

基于RTC场景下要解决的声音的问题，WebRTC有一个大体如下图所示的音频处理流水线WebRTC的音频处理流水线，不是一次性建立起来的，而是分阶段分步骤建立的。整体而言，可以认为这个流水线分两个阶段建立，或者可以认为这个流水线分为两部分一部分可称为静态流水线，另一部分可称为动态流水线，或者也可以称为前端和后端。静态流水线，在某个时间点建立一次，随后在整个WebRTC通信过程中基本保持不变；......

WebRTC 作为一个实时音视频通信系统，包含了信令控制、音视频传输、音视频采集、音视频编码、音视频解码、音视频渲染等所有功能。由于其功能多样性，注定了系统结构的复杂性，再加上音视频需要做很多编码前后的处理，算法非常复杂，逻辑结构也复杂。为了在复杂网络环境下，保证音视频通信的流畅性，WebRTC 还做了很多流控、带宽预测、拥塞控制算法。为此，为了降低系统的复杂性，提高系统的运行效率，WebRTC 设计了一套多线程框架，并且做了精心的设计。下来我们就分析一下 WebRTC 中的线程模型。WebRTC 的线程模

目前总结出webrtc用于提升QOS的方法有：NACK、FEC、SVC、JitterBuffer、IDR Request、PACER、Sender Side BWE、VFR（动态帧率调整策略）、AVSync（音视频同步）、动态分辨率调整。这几种方法在webrtc架构分布如下：具体实现原理如下：一、NACK与NACK对应的是ACK，ACK是到达通知技术。以TCP为例，他可靠因为接收方在收到数据后会给发送方返回一个“已收到数据”的消息（ACK），告诉发送方“我已经收到了”，确保消息的可靠。NA

视频会议中通常使用的FEC/QOS技术，这方面的资料比较复杂和稀少，根据这么多年的工作经验，做一下分享。在IP视频通话中丢包造成的影响多种多样。其中对视频质量的影响主要有：马赛克现象、局部变形(图像的某些区域不清晰)、图像模糊、屏幕频繁刷新或闪烁、视音频不同步、帧率下降、图像静止等等。对音频质量的影响包括：总体音频失真、间断或间歇性噪音、音频中断等。而对内容和演示数据质量的影响则包括：幻灯片模糊变形、翻页速度减慢或屏幕频繁刷新和图像静止等等。另外，丢包还会引起过度延迟，甚至是通话中断。...