【音视频第5天】回声、音频丢包补偿、多人聊天架构、实时音视频传输协议、P2P
《即时通讯音视频开发（一）：视频编解码之理论概述》
《即时通讯音视频开发（二）：视频编解码之数字视频介绍》
《即时通讯音视频开发（三）：视频编解码之编码基础》
《即时通讯音视频开发（四）：视频编解码之预测技术介绍》【没看】
《即时通讯音视频开发（五）：认识主流视频编码技术H.264》【没看】
《即时通讯音视频开发（六）：如何开始音频编解码技术的学习》【没看】
《即时通讯音视频开发（七）：音频基础及编码原理入门》
《即时通讯音视频开发（八）：常见的实时语音通讯编码标准》
《即时通讯音视频开发（九）：实时语音通讯的回音及回音消除概述》
《即时通讯音视频开发（十）：实时语音通讯的回音消除技术详解》
《即时通讯音视频开发（十一）：实时语音通讯丢包补偿技术详解》
《即时通讯音视频开发（十二）：多人实时音视频聊天架构探讨》
《即时通讯音视频开发（十三）：实时视频编码H.264的特点与优势》【没看】
《即时通讯音视频开发（十四）：实时音视频数据传输协议介绍》
《即时通讯音视频开发（十五）：聊聊P2P与实时音视频的应用情况》
《即时通讯音视频开发（十六）：移动端实时音视频开发的几个建议》
《即时通讯音视频开发（十七）：视频编码H.264、VP8的前世今生》【没看】
《即时通讯音视频开发（十八）：详解音频编解码的原理、演进和应用选型》【没看】
《即时通讯音视频开发（十九）：零基础，史上最通俗视频编码技术入门》（必读）【没看】
另外，《移动端实时音视频直播技术详解》这个系列文章能很好地对应上我刚说的这些技术点，建议读一读：
《移动端实时音视频直播技术详解（一）：开篇》
《移动端实时音视频直播技术详解（二）：采集》
《移动端实时音视频直播技术详解（三）：处理》
《移动端实时音视频直播技术详解（四）：编码和封装》
《移动端实时音视频直播技术详解（五）：推流和传输》
《移动端实时音视频直播技术详解（六）：延迟优化》
回声
产生回声的原因
从通讯回音产生的原因看，可以分为声学回音（Acoustic Echo）和线路回音（Line Echo），相应的回音消除技术就叫声学回音消除（Acoustic Echo Cancellation，AEC）和线路回音消除（Line Echo Cancellation, LEC）。
声学回音是由于在免提或者会议应用中，扬声器的声音多次反馈到麦克风引起的（比较好理解）；
线路回音是由于物理电子线路的二四线匹配耦合引起的（比较难理解）。
消除回声的步骤
echo=F（fe）函数F被称之为回音路径，混合信号1叫做近端信号ne，虚线信号2叫做远端参考信号fe
- 房间A的音频会议系统接收到房间B中的声音
- 声音被采样，这一采样被称为回音消除参考
- 随后声音被送到房间A的音箱和声学回音消除器中
- 房间B的声音和房间A的声音一起被房间A的话筒拾取
- 声音被送到声学回音消除器中，与原始的采样进行比较，移除房间B的声音
实时语音通讯丢包补偿技术
丢包补偿技术可以分为两类：基于发送端补偿和基于接受端补偿。基于发送端补偿包括前向差错纠正、交织和重传技术；基于接受端补偿包括了多种错误隐蔽算法。
基于发送端的丢包补偿技术原理
FEC
与媒体无关的FEC
这种方式中每n个媒体数据包附带k个校验包。校验包的每个比特都是由相关的数据包的同位置比特产生的。每4个媒体数据包附带1个校验包的情况
与媒体相关的FEC
采用多个包传送同样的音频单元。一旦丢了一个，信息可以从另外一个包含该单元的恢复出来。图3表示了媒体相关前向差错纠正的原理。
第一个传输的复本称为主要编码，第二个传输的复本称为次要编码。次要编码可以是和第一个相同，但是大部分采用较低码率和较低音质的编码技术。编码器的选择取决于带宽需求和计算复杂度需求。
交织
当我们考虑比语音包还小的语音单元并且可以承受较大的延时，交织是一种很有用的抗丢包技术。语音单元在传输之前重新排序，这样在传输流中原来领近的语音单元变成有规律间隔的单元，接收端再按原来的顺序排列回来。显示20ms包分为5ms单元的例子。可以看到传输的一个丢包变成了分散的多包中的单元丢失。
基于接收端的丢包补偿技术原理
当发送端不能做到较好的丢包补偿或发送端不能参与丢包补偿时，需要在接受端进行丢包补偿。错误隐蔽算法就是接受端的丢包补偿技术，它产生一个与丢失的语音包相似的替代语音。这种技术的可能性是基于语音的短时语音相似性，它可以处理较小的丢包率（<15%）和较小的语音包（4-40ms）。当丢包的长度达到音素的长度（5-100ms），该技术就不适应了，因为整个音素都会丢失。
多人实时音视频聊天架构
多人实时音视频架构1：Mesh结构
这是最简单的多人视频通话架构模式，所有媒体流都不需要经过服务端，客户端直接P2P，可通过webrtc建立多个PeerConnection，结构图如下:
该方案优点:
服务端压力最小，大多数情况下不需要用到流媒体服务。
该方案缺点:
客户端负载太大，不事宜扩展，特别是移动端，编解码压力会非常大。
多人实时音视频架构2：Mixer结构
视频会议基本上就是种结构，他的最大特点就是服务端做了很多事情，包括转码，混音，合屏，所以服务端负载非常大，结构图如下:
该方案优点:
客户端负载最小，与一对一负载一样，所以理论上可以支持很多人同时视频。
因为服务端有做编解码，所以可与现有产品无缝集成。
可以最大程度利用硬件能力，如硬件MCU，芯片。
该方案缺点:
服务端负载很大，建设成本很高。
延迟问题，因为服务端做了很多动作(解码，合屏，混音，编码)，所以会带来延迟。
多人实时音视频架构3：Router结构
该方案最大特点就是服务端只负责包转发，不负责转码，yy流媒体服务基本上就是这个功能，结构图如下：
该方案优点:
与Mixer相比服务端压力比较小，而且容易扩展。
低延迟，特别是与SVC结合能大大提升客户端体验度(貌似h265和vp9才开始集成svc)。
该方案缺点:
考虑到不同客户端需要不同的接收能力，所以真正实现下来服务端的架构也并不简单。
实时音视频传输协议
RTP协议
RTP传送具有实时属性的数据
RTCP协议
RTCP为RTP媒体流提供信道外（out-of-band）控制。不传输数据，但和RTP一起协作将多媒体数据打包和发送。RTCP定期在流多媒体会话参加者之间传输控制数据。RTCP的主要功能是为RTP所提供的服务质量（Quality of Service）提供反馈。
SRTP、SRTCP协议
安全实时传输协议（Secure Real-time Transport Protocol或SRTP）是在实时传输协议（Real-time Transport Protocol或RTP）基础上所定义的一个协议，旨在为单播和多播应用程序中的实时传输协议的数据提供加密、消息认证、完整性保证和重放保护。
RTSP协议
点播
RTP不象http和ftp可完整的下载整个影视文件，它是以固定的数据率在网络上发送数据，客户端也是按照这种速度观看影视文件，当影视画面播放过后，就不可以再重复播放，除非重新向服务器端要求数据。
RTSP与RTP最大的区别在于：RTSP是一种双向实时数据传输协议，它允许客户端向服务器端发送请求，如回放、快进、倒退等操作。当然，RTSP可基于RTP来传送数据，还可以选择TCP、UDP、组播UDP等通道来发送数据，具有很好的扩展性。它时一种类似与http协议的网络应用层协议。
P2P与实时音视频的应用情况
P2P技术简介
p是peer的缩写，p2p就是点对点，两个客户端直接进行数据交互，不需要经过服务器转发(relay)，这种方式能大大减轻服务端的负载，所以特别视适合大数据的传输，比如实时音视频聊天、在线视频直播、大文件传输等应用场景。
如果遵循ICE协议，基本上能打洞成功的网络他都能p2p，不能打洞成功的网络基本上都是跟路由器类型有关，与技术无关。
googActualEncBitrate 视频编码器实际输出的码率，一般和目标码率是匹配的
googAvailableReceiveBandwidth 接收视频数据可用的宽带
googAvailableSendBandwidth 发送视频数据可用的宽带
googBucketDelay Google为处理大数据速率的策略表示，一般是很小的数值
googRetransmitBitrate 如果RTX被使用的话，表示重传的码率，此数据通常代表丢包率
googTargetEncBitrate 视频编码的目标码率
googTansmitBitrate 实际发送传输的码率，如果此数值与googActualEncBitrate有较大的出入，可能是受fec(前向纠错)影响
mediaType 媒体类型video/audio
packetsSent 累计发送的数据包数
googJitterReceived 接收到多少抖动
id 后缀用来区分是发送或接受的ssrc,发送: _send,接收: _recv
googTrackId 音频或视频TrackId
googRtt 全称为:Round-trip time,表示的是请求的往返时间,是发送端从接收端发送过来的RTCP中得到时间戳通过计算得到往返时延
transportId 指向传输RTP流的部分，通常于音频或视频流的transportId是一样的
googCodecName 编码器的名称,音频一般是opus,视频一般为:VP8、VP9、H264
codecImplementationName 具体实现编码器的名称，一般MediaCodec等
audioInputLevel 发送端采集的音频能量大小
audioOutputLevel 扬声器播放的音量大小
bytesSent 累计发送数据的字节数
framesEncoded 累计编码出的视频帧数量
packetsLost 累计丢包数量，对于发送端从接收端发送过来的RTCP Receiver Report中得到累计丢包数量，可以和googNacksReceived数据进行对照，对于接收端来说，丢包数量是本地测量出来的。
googNacksReceived 发送端收到的重传包请求(nack)数量，可以和packetsLost进行对照
qpSum 全称为uantization Parameter,发送端编码出的带有量化参数(QP)值的帧的数量，一般来说，这个数字越高，视频轨道压缩的越严重，需要注意，QP值可能因编码器不同而不同，所以此值仅在与同一编码器进行比较时可能有用
googAdaptationChanges 发送端因为CPU的负载变化导致的分辨率变高或变低的次数，需要设置googCpuOveruseDetection
googAvgEncodeMs 发送端平均编码时间，值越小越好
googBandwidthLimitedResolution 是否因为宽带受限而降低发送的视频分辨率
googCpuLimitedResolution 是否因为CPU不足而降低发送的视频分辨率
googEncodeUsagePercent 发送端(平均每帧编码时间)/(平均每帧采集时间)，主要是用来反映编码效率
googFirsReceived 发送端收到的关键帧请求数量，Fir全称为:Full Intra Request,一般来说在video conference模式下，有新的参与者进来会发出
*googPlisReceived 发送端收到的古建筑请求数量, pli全称为icture Loss Indication,一般来说接码失败时会发出
googFrameHeightSent 发送端发送的视频分辨率高度，根据当前网络会进行动态调整
googFrameWidthSent 发送端发送的视频分辨率宽度，根据当前网络会动态调整
googFrameRateInput 发送端设置的初始帧率
googFrameRateSent 发送端实际发送的帧率，根据当前网络会动态调整
googFrameHeightReceived 接收到的视频分辨率高度
googFrameWidthReceived 接收到的视频分辨率宽度