1.1 两条技术路线
1.1.1 以音视频会议为代表的实时互动直播
互动直播主要解决音视频远程交流问题，实时性较强，时延一般低于500ms。
1.1.2 以娱乐直播为代表的流媒体分发
娱乐直播主要解决音视频大规模分发问题，实时性较差，时延一般在3s以上。
1.2 直播技术
WebRTC用于实时互动直播，RTMP、HTTP-FLV、HLS、DASH用于娱乐直播。
1.3 现状与未来
1.3.1 现状
实时互动直播与娱乐直播技术相结合成为现在直播服务器的主流技术方案。
WebRTC不仅可以用在浏览器之间进行音视频互动，还可以用在P2P传输、文本聊天、文本传输、游戏、多人实时互动、音频处理（回音消除、降噪）等应用中，甚至是人工智能软件上。
在一些实验产品中，可以使用RTMP推流，然后在浏览器上使用WebRTC技术拉流观看，这种技术对于视频监控行业是个不错的解决方案。
1.3.2 未来
可以利用AI、深度学习技术对音视频数据做二次处理，将这些非结构化数据转变成结构化数据（存入数据库或保存成格式化文件），再利用大数据技术分析生成各种报表，为业务提供支持和服务。
将AI和大数据分析速度提升到实时处理级别，让产品可以根据视频中用户的面部表情、行为举止实时改变服务内容。
1.4 自研直播架构
1.4.1 客户端架构
音频采集PCM数据，视频采集YUV数据。
音频有独立的采集设备（麦克风/话筒）、独立的播放设备（扬声器）、访问音频设备的系统API、多种音频编解码器（如Opus、AAC、iLBC、G.711/G.722、Speex）等。
视频也有自己的采集设备（摄像头）、渲染设备（显示器）、各种视频编解码器（如H264、VP8、H265、VP9、AVI）等。
在音视频处理中，一般称每一路的音频/视频为一条轨。
1.4.2 跨平台架构
1.4.3 插件化管理
1.4.4 其他问题
1）音视频不同步：增加音视频同步模块。
2）3A：AEC（Acoustic Echo Cancelling，回音消除）、AGC（Automatic Gain Control，自动增益控制）、ANC（Active Noise Control，降噪）。
3）音视频的实时性：网络质量很关键，物理层很难保障，需要在软件层加以控制。
4）网络拥塞、丢包、延时、抖动、混音等。
1.4.5 自研系统与WebRTC比较
1.5 音视频实时通信目标
目标：尽可能逼近或达到面对面交流的效果。
两种指标：实时通信延迟指标和音视频服务质量指标。
1.5.1 实时通信延迟指标
端到端之间，引起延迟的因素有：音视频采集时间、编解码时间、网络传输时间、音视频的渲染时间、各种缓冲区所用的时间等。
1.5.2 视频相关概念
1）分辨率：指图像占用屏幕上像素的多少。对实时通信而言，图像默认分辨率一般设置为640*480或640*360。
2）帧率：指视频每秒放帧（图像）的数量。对实时通信而言，当帧率小于15帧/秒时，会感觉视频质量不佳，卡顿严重。
3）码率：指视频压缩后，每秒数据流的大小。相同分辨率下，码率越大（MOS <= 5）还原度越好，图像越清晰。
1.5.3 影响网络质量因素
1）丢包：网络质量最重要的指标，对网络影响最大。对WebRTC而言，大于2%且小于10%的丢包率是正常的网络。
2）延迟：也是网络质量的重要指标。如果两端之间延迟持续增加，说明网络线路很可能发生了拥塞。
3）抖动：对网络质量影响最小。如果抖动很小，通过循环队列将其消除；如果抖动过大，将乱序包当作丢包处理。在WebRTC中，抖动时长不能超过10秒，超过10秒就认为该包丢了。
1.5.4 提高音视频服务质量
1）增加带宽
① 5G落地：全面覆盖。
② 客户端WebRTC支持选路方案：按优先级选择最优质的的网络连接线路。
③ 服务端方案：提供更优质的接入服务（让用户连接同一地区、同一运营商的接入服务器），保证云端网络的带宽和质量（可以购买优质的BGP网络作为云内部使用），更合理的路由调度策略（选择距离最近、网络质量最好、服务器负载最小的线路）。
2）减少数据量
减少音视频数据量是以牺牲音视频服务质量为代价。
① 更好的压缩算法：H265压缩率比H264提高了25%左右，AVI在veryslow模式下压缩率比H264提高了40%左右。
② SVC技术：将视频按时间、空间及质量分成多层编码，将它们装在一路流中发给服务端。服务端再根据用户带宽情况选择不同的层下发。
③ Simulcast技术：与SVC技术类似，实现比SVC简单。将视频编码出多种不同分辨率的多路码流发给服务器，服务器根据用户带宽情况选择其中一路最合适的码流下发。
④ 动态码率：当评估出用户带宽不够时通过编译器让其减小输出码率；当评估出带宽增大时增大输出码率。
⑤ 甩帧或减少业务：甩帧或关闭某些不重要的业务。
3）适当增加时延
增加时延，即先将数据放到队列中缓冲一下，然后再从队列中获取数据进行处理，使数据变得"平滑"。
实时音视频直播须将时延控制在一定范围内（单向延迟小于500ms）。
音视频的采集、编解码、渲染等时间是固定的，可以将网络时延计算出来，就可以确定缓冲区的时延。
4）提高网络质量
① NACK/RTX ：NACK是RTCP中的一种消息类型，由接收端向发送端报告一段时间内有哪些包丢失了；RTX是指发送端重传丢失包，并使用新的SSRC将传输的音视频包与重传包进行区分。
② FEC前向纠错：使用异或操作传输数据，以便在丢包时通过这种机制恢复丢失的包。FEC特别适合随机少量丢包的场景。
③ JitterBuffer防抖动：可以将抖动较小的乱序包恢复成有序包。
④ NetEQ：专用于音频控制，里面包括了JitterBuffer，另外还利用音频的变速不变调机制将积攒的音频数据快速播放或将不足的音频拉长播放，以实现音频的防抖动。
⑤ 拥塞控制：
WebRTC中拥塞控制算法：GCC（Google Congestion Control，Google拥塞控制）、BBR（Bottleneck Bandwidth and Round-trip propagation time，瓶颈带宽和往返传播时间）、PCC（Performance-oriented Congestion Control，基于性能的拥塞控制）
GCC根据实现分为：基于发送端的拥塞控制算法Transport-CC（Transport-wide Congestion Control，传输带宽拥塞控制），基于接收端的拥塞控制算法Goog-REMB（Google Receiver Estimated Maximum Bitrate）。
5）快速准确评估带宽
实时通信领域有四种常见的带宽评估方法：Goog-REMB、Goog-TCC、NADA、SCReAM。文章来源：https://www.toymoban.com/news/detail-834593.html
NADA在准确性和及时性方面好于GCC，GCC在网络使用的公平性方面比NADA更具优势。在有丢包情况的网络下，NADA表现极差，无法与GCC相比。SCReAM在各方面的表现都有失水准。文章来源地址https://www.toymoban.com/news/detail-834593.html
到了这里，关于WebRTC技术文档 -- 1.音视频直播（笔记）的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
