直播弱网优化方法
原创
背景
直播平台纷繁杂多，流量入口逐渐从传统PC端过渡至移动端。直播规 模爆发式增长，2016年更是被誉为“直播元年”。以游戏为代表的泛娱乐直播是这一时期直播生态的重要组成部分。2015-2017年，4G技术普及，手机直播由于不受设备、场景等限制开始迅速普及，推动全民直播的出现；同时，由于直播功能的创新、直播平台以及资本的纷纷入局、政策支持，直播行业一度出现“千播大战”局面。期间，政府出台《电子竞技赛事管理暂行规定》等游戏行业相关政策，进一步推动了游戏直播的发展。
商业变现期： 行业稳定发展，流量红利渐退，政策监管趋于规范，电商直播于电商平台和短视频平台兴起，逐渐成为直播行业重要变现形式。虎牙等游戏直播平台也开始盈利。2018年，淘宝直播有81名主播成交额破亿，超过400个直播间每月带货超过100万元；同年，虎牙首度盈利，全年营收46.6亿元，净利润4.6亿。2019年，淘宝直播在双十一期间仅用了8小时55分，实现引导成交破百亿；而虎牙也实现再度盈利，净利润增至7.5亿，另一头部游戏直播平台斗鱼也扭亏为盈，全年营收72.8亿元，净利润3.5亿。直播的商业价值凸显。
受黑天鹅事件“疫情”影响，线上化需求强烈，多行业青睐直播形式，加速直播行业的发展与渗透。2020年，疫情突发事件进一步拓展了直播的辐射范围。从直播平台来看，多个平台开发直播功能、开放直播流量入口、出台直播扶持政策；从直播品类来看，教育、汽车、房产等以线下运营为主的行业也开始试水线上直播；从直播主播来看，主播群体更加多元，除了直播达人，越来越多的明星、KOL、商家、政府官员等开始进入直播领域。据中国互联网络信息中心数据显示，截至2020年3月，直播用户规模达 5.60亿，即40%的中国人、62%的网民是直播用户。其中，电商直播用户规模为2.65亿。受疫情影响，“直播”形式在多个行业的关注度均有提升，预计2020年度数据再创新高。
名词术语
QoE表示用户在接收端的主观体验。
QoS是指通过一些量化指标衡量网络的传输质量并提供优质网络的服务。
HDS Http Dynamic Streaming（HDS）是一个由Adobe公司模仿HLS协议提出的另一个基于Http的流媒体传输协议。其模式跟HLS类似，但是又要比HLS协议复杂一些，也是索引文件和媒体切片文件结合的下载方式。
问题
2021年2月3日，中国互联网络信息中心（CNNIC）发布第47次《中国互联网络发展状况统计报告》（以下简称《报告》）。《报告》显示，截至2020年12月，中国网民规模达9.89亿，较2020年3月增长8540万，互联网普及率达70.4%。
报告分析，随着网络扶贫行动带动边远贫困地区非网民加速转化，在网络覆盖方面，贫困地区通信“最后一公里”被打通，因而农村网民贡献了主要互联网用户增量。其中，中国农村网民规模达3.09亿，占网民整体的31.3%，较2020年3月增长5471万；城镇网民规模达6.80亿，占网民整体的68.7%，较2020年3月增长3069万。
中国的城镇化率约60%，农村住了约40%的人。在城市里，能支撑起视频直播的网络坏境，家庭wifi网络，办公工作网络，酒店，商场以及大型超市移动网络。户外，如地铁，公交，公园，体育馆等，网络信号差，收费贵，网络带宽遭抢占，很难满足视频直播。
目前移动端产品的使用用户所处的网络并非完全的流畅WIFI环境，仍有相当多的用户主要使用4G、3G、2G等网络，另外因移动端产品使用场景多变，如进地铁、上公交、进电梯等，网络环境复杂，信号稳定性也非常差。
目前国内网络环境比较稳定的环境，家庭wifi网络，办公工作网络，商场以及大型超市。相对于农村，城市的网络基础设施，移动运营商的基站覆盖也要好很多。在城市里面，网络基础设施也不是所有的地方都有覆盖，能支持视频直播的网络环境少之又少，户外基本上都不适合直播观看。相对于直播而言，目前国内绝大部分网络环境都是弱网。因此弱网是直播不得不面对的问题。
直播音视频数据的传输，传输的数据量大，对延迟要求高，数据实时产生的，不能提前进行预取，因此对网络要求非常高，网络质量不好，或者带宽不足，观众不能及时的收到视频数据，观看体验非常差。
弱网定义
衡量网络的指标
衡量网络质量的指标主要有以下几个：
1、RTT，RTT越小越好，越稳定越好，RTT越小，数据传输的越快。
2、带宽，带宽越大，单位时间内传输的数据越多。
3、丢包率，丢包率越小，重传概率越低，数据传输成功率越高。
4、吞吐量，单位时间内传输的数量越大，网络质量越好。
弱网环境是丢包率较高的特殊场景，TCP 在类似场景中的表现很差，当 RTT 为 30ms 时，一旦丢包率达到了 2%，TCP 的吞吐量就会下降 89.9%，从上面的表中我们可以看出丢包对 TCP 的吞吐量极其显著的影响。
弱网模拟一些场景：
普通的弱网定义
在当今移动互联网盛行的时代，网络的形态除了有线连接，还有2G/3G/Edge/4G/Wifi等多种手机网络连接方式。不同的协议、不同的制式、不同的速率，使移动应用运行的场景更加丰富。
从测试角度来说，需要额外关注的场景就远不止断网、网络故障等情况了。对于弱网的数据定义，不同的应用所界定的含义是不一样且不清晰的，不仅要考虑各类型网络最低速率，还要结合业务场景和应用类型去划分。按照移动的特性来说，一般应用低于2G速率的都属于弱网，也可以将3G划分为弱网。除此之外，弱信号的Wifi通常也会被纳入到弱网测试场景中。
直播音视频弱网定义
如果直播需要正常播放，需要能快速传输足够多的音视频数据。只要播放器能够收到足够多的数据，视频就能正常播放。否则就会出现缓冲或者播放异常，其中网络原因占90%以上，我们称之为弱网。
视频直播网络异常原因如下：
1、 网络带宽低于视频直播的码率。
2、 网络丢包高，导致频繁重传，消耗了本来不充足的带宽。
3、 网络抖动，网络带宽波动较大，网络拥塞。
4、 网络信号弱，频繁断网重连。
上述4个条件，满足一个，就可以称之为音视频弱网，即由于网络原因，不能正常传输音视频数据。
按照音视频弱网定义，国内的网络环境，有线网络，家庭和办公的wifi网络外，其他都属于弱网，4g网络在人少，城市中心，勉强可以播放视频数据，人聚集多了，网络质量就没有办法保障，如果大家一起用4g播放视频，很容易出现互相抢带宽，基本上没有办法观看了。在音视频场景下，4g网络的质量是没有办法保障，因此也算是弱网。4g场景下，卡顿时长是wifi场景下2～3倍。
解决方案
弱网问题解决根本办法，是提升现在网络质量，建设更多的网络基础设施。网络基础设施的建设，不仅需要政府投入大量的资金，而且建设周期也非常长，因此在短时间内很难有较大幅度的改善，且不受个人或者公司控制的。
弱网用户观看体验比较差，根本原因是网络带宽不够，不能在有限的时间内，下载到足够多的视频数据。解决问题的方向，通过降低画质，或者丢掉部分视频数据，亦或提高视频数据的压缩率等，降低观看所需要的数据量，降低网络负载。
1. 用户被动切换码率
播放器感知到的网络质量情况，告知用户，让用户来降低清晰度播放，具体操作如下：
此种方式，用户会有感知，把决策权交给客户。从网络质量从好变到差，会有较多的提示，体验比较好，但网络质量从差变到好的情况下，没有任何提示，体验不好，不能恢复。如果网络质量频繁变化，用户会频繁的切换，会导致用户体验快速下降，导致用户放弃观看。
把决策权交给客户，给客户印象，是不智能，也不能较好的利用网络带宽，为了能提高带宽的利用率，提高用户观看体验，需要走播放器和后台自动控制的逻辑。
2. 终端自适应码率
播放器端根据不同的网络模型，评估网络带宽，并根据网络带宽情况，从服务器端下载不同码率的流。弱网情况下，从服务器端下载低码率的流，通过减少网络中传输的数据，来提升用户的观看体验。
如果是网络质量是不断的变化的，可以根据实际的网络情况，动态调整拉流的码率。直播流的分发主要有两种方式，一种是通过分片进行分发，即分片下载，采用的是短链接，如DASH，HLS等，一种是通过长链接的方式，在单个链接里面，下发所有音视频数据，如flv，rtmp等。
DASH/HLS实现比较容易，在索引文件把所有码率的分片索引都带上，客户端根据实际的网络情况，选择合适的分片进行下载。换不同的分片下载比较方便，换一个分片地址就可以，不需要进行额外的变更。这里需要注意的是不同码率之前的切片的时间戳需要对齐，在切换码率过程中，不能出现画面跳跃，或者画面渲染失败的情况。
分片模式实现自适应码率的逻辑，其中的关键是索引文件MPD。索引文件下载和分片下载可以复用一个链接，以降低握手的开销。具体MPD结构如下：
由于HLS/DASH的分片之间没有相互依赖，边界还可以通过关键帧来进行对齐，不同的码率之间可以进行无缝切换。
HLS/DASH的延迟一般较大，虽然可以通过减小分片来降低一些延迟，但是会受到索引文件，GOP等因素的限制。
FLV/RTMP，是长链接，不同码率的地址是按照固定的规则生成，通过pts进行对齐，都是从关键帧开始下发。P帧和B帧，解码是需要依赖其他帧的，不能单独渲染的，所以必须在关键帧的进行切换。从P帧和B帧对齐，实现比较复杂，不同码率的流，帧率有可能不一样，时间戳不一定能完全对齐。长连接模式，不同码率的流，使用的是不同的链接。使用http2技术，可以复用连接。
自适应码率切换过程中，需要解决两个问题，第一个问题是边界对齐，不同码率在切换的时候，要求画面平滑，不能进行跳跃，影响客户观看，在切片的时候加入额外的信息进行标识，就可以解决。
第二个问题是码率切换策略，主要是在播放器端进行处理的，码率切换策略可以分为以下几种：
1、 Buffer-based：基于客户端的播放缓冲区buffer的情况决策下一个片段的码率档位。
2、 Rate-based：基于预测的带宽去决策下一个片段的码率档位。
3、 同时考虑预测带宽和buffer信息决策下一个片段的码率档位。
想要设计合理的码率切换算法，既要考虑带宽和缓冲区长度，又要考虑码率切换频率和切换幅度，最后可能还要考虑直播内容。
目前主要用的是快手，下面是快手的实现方案：
https://cloud.tencent.com/developer/article/1652531
3. 分层编码/丢帧（SVC）
H.264 SVC (Scalable Video Coding)是以H.264为基础，在语法和工具集上进行了扩展，支持具有分级特性的码流，H.264SVC是H.264标准的附录G，同时作为H.264新的profile。H.264SVC在2007年10月成为正式标准。
编码器产生的码流包含一个或多个可以单独解码的子码流，子码流可以具有不同的码率，帧率和空间分辨率。
分级的类型：
时域可分级（Temporal scalability）：可以从码流中提出具有不同帧频的码流。
空间可分级（Spatial scalability）：可以从码流中提出具有不同图像尺寸的码流。
质量可分级（Quality scalability）：可以从码流中提出具有不同图像质量的码流。
SVC分级编码的应用：
1. 监控领域：监控视频流一般产生2路，1路质量好的用于存储，1路用于预览。用SVC编码器可以产生2层的分级码流，1个基本层用于预览，1个增强层保证存储的图像质量是较高的。使用手机远程监控预览的情况下，可以产生一个低码率的基本层。
2. 视频会议领域：视频会议终端利用SVC编出多分辨率，分层质量，会议的中心点替代传统MCU二次编解码方法改为视频路由分解转发。也可在网络丢包环境下利用时域可分级，抛弃部分时域级实现网络适应性。在云视讯领域SVC也有想像空间。
3. 流媒体IPTV应用：服务器可以根据不同的网络情况丢弃质量层，保证视频的流畅。
4. 兼容不同网络环境和终端的应用。
优点：分级码流优点是应用非常灵活，可以根据需要产生不同的码流或者提取出不同的码流。使用SVC实现一次分层编码比用AVC编多次更高效。分层编码有技术优势，新的编码器H.265也使用了分层思想，可以实现灵活的应用，也可提高网络适应性。
SFU从发布客户端复制音视频流的信息，然后分发到多个订阅客户端。典型的应用场景是1对多的直播服务。
SFU是解决服务端性能问题的好方法，因为它不涉及视频解码和编码的计算费用，它以最低的开销来转发各路媒体流。能实现海量的客户端接入。重终端，轻平台。但是分层编也可能AVC的Simulcast技术实现相似的效果。
SVC编码用于编码层的FEC。图像编码层的前向纠错，如果编码数据有缺失，可以用另一层的数据来弥补。 但用过网络层的FEC也可以实现相似的效果。
缺点：分级码流的解码复杂度增加。基本层是AVC兼容码流，编码效率没有影响。在同样的条件下，分级码流比单层码流的压缩效率要低10%左右，分级层数越多，效率下降越多，现在的JSVM编码器最多支持3个空域分级层。在同样的条件下，分级码流比单层码流的解码计算复杂度高。SVC是2007年10月才做为正式标准，兼容性和对通性远没有AVC好，所以SVC实际应用不是广泛。
正是因为SVC解码控制复杂不利于流式处理，绝大部分硬编解码器都不支持，即使很小部部分支持的也是时域分层（不同帧率），仅分两层，倍数关系，如30帧/15帧，这种分层在AVC现在基础上做很小的改动即可。业界SVC基本是软件实现，或DSP等可编程实现。
SVC理论可以从时域，空域，质量分层，分多层，导致协议协商的细节多和复杂，标准不统一，每家的SVC实现也不一样。目前业界没有谁的产品能做SVC码流对通，一家也没有。说能SVC对通的都是媒体网关，需要二次转码。能做到AVC的通过的也是媒体网关。
上面简单的介绍了一下SVC技术，直播可以采用时域分级进行编码，根据网络情况，获取不同帧频的码流，丢弃部分层级的的视频帧，提高弱网环境的直播体验。
注：可以通过依次丢弃棕色、绿色、蓝色得到不同帧频的码流。
4. 客户端和服务器端配合进行丢帧
AVC编码的视频帧之间是有相互依赖的，不能随意丢，如果丢掉帧被其他视频帧参考，参考该帧的视频帧，会解码失败，导致出现花屏。直播过程中I帧，是独立的帧，不依赖于其他帧可以进行渲染，占用字节数比较大，是最重要的视频帧。P帧依赖于I帧或者P帧，都是向前依赖。B帧是最小的依赖于前面和后面的帧，也是依赖性最强的帧，不会被参考，因此重要最低，可以随意丢弃的。
一个画面组GOP，有I帧，P帧，B帧组成。可以根据重要性以及依赖性，进行选择性丢帧，具体丢帧策略如下：
1、 丢掉B帧
2、 从GOP中某个P帧开始，丢掉该GOP
3、 丢掉GOP中所有的B帧和P帧，保留I帧。
4、 丢掉整个GOP。
注意：由于音频数据非常少，对整体数据量影响很小，一般为了确保播放器能够正常的解码，是不会丢音频帧的。从1到4，丢帧比例越来越高，策略越来越激进。
丢帧除了怎么丢之外，还需要知道什么时候丢，需要精准的判断网络所处的状态，目前大多数丢帧都是通过应用层发送队列堆积的长度来判断，堆积的数据超过5s，就开始进行丢帧，从1～4逐步实施，如果队列长度逐步增加，就会主播进入丢帧比例更好的状态。
进入丢帧状态后，需要周期性的探测网络是否恢复，恢复的条件：如果队列为空时间超过一定的阈值，比如5s，措施就进行回退，如从4回退到3，逐步进行恢复。
上述丢帧策略仅仅依赖服务器端的探测，服务器端的探测需要一定的时间，网络频繁抖动的场景下，还会出现策略频繁的调整，导致用户观看体验下降。
如果客户端能主动告诉服务端用户的网络情况，可以节省探测时间，服务端可以结合客户端和服务端的情况，进行综合决策。降低探测成本，减少切换频次，提升用户的观看体验。
5. RTMP 302断流重推
我们以一个现网实际的case来引入该问题，2021年3月9日，巴西地区的主播，下图是该流的推流帧率曲线：
在20:50-21:50这段时间整体的推流帧率非常低，丢帧非常严重，但用户量非常大，有5w+人在线，下行近100G播放带宽
从cdn播放质量维度来看，对应时间段，卡顿率非常高，观看质量非常差。
紧急情况中，采取了断流迫使推流端重新推流，快速恢复了推流的稳定。
如上图所示，在21点47分左右，重新推流后，推流帧率稳定在30帧，卡顿率也恢复到正常水平。
经分析，该主播是在巴西，上行接流也在巴西，服务端存在大量的慢速日志：
其实这种由于单个tcp连接慢速问题，在海外复杂的推流环境中经常发生。海外的链路比较复杂，而且链路非常长，有时刚开始推流质量非常稳定，时间长了，网络出现抖动后，就会出现上述网络变差的情况，导致数据传输不稳定。
欧美等发达国家网络质量好，带宽比较充足，都能满足正常的直播推流。在一些发展中国家，比如中东，东南亚，电信基础设置比较差，网络带宽不足，本地运营商存在各种带宽限制。很容易出现推流一段时间后，出现网络不稳定的情况，断流重推后就能恢复正常。为了避免调度到同一个节点上，通常通过配置host的方式，指定接入节点，来避免调度到同一个节点，来恢复正常推流。
上述的异常情况，一般通过断流重推或切换推流节点的方式，往往能解决大部分的问题。服务器端主动断主播连接风险很高，如果推流端处理不好，还会出现主播推流异常，导致推流失败，很容易引起投诉，因此通常需要人工进行处理。人工处理的缺点很明显，成本高，问题处理不及时，处理问题时间长等。
为了解决上述问题，利用rtmp302特性，制定了一个改进方案。服务器端如果检测到推流有慢速，通过amf控制消息的方式，将新的推流接地址，发送给推流端，推流端结合本地网络情况，来进行综合决策是否要进行断流重推。
本方案的亮点是服务端只提供建议，不做决策，客户端可以结合终端和后台提供的信息，进行综合评估，对比单方面决策，可以大幅提升决策的准确性。
为了解决推流过程中，网络异常问题，采用了RTMP 302 重定向的方案，具体实现逻辑如下图所示：
步骤一，推流过程中，rtmp server端支持持续弱网检测，支持域名+发布点维度的配置化的弱网检测。
步骤二，检测到该情况发生后，需要向调度系统，根据客户端IP，请求一个合法、高质量的推流接入节点IP，拼接完整的重定向推流地址，通过amf data给到推流客户端。
步骤三，推流客户端识别对应的amf data，
推流终端拿到redirect中的重定向地址后，综合本地信息，判断是否需要断流重推，如果需要，进行使用服务器端提供的地址重新推流，解决慢速问题。
上述解决方案，在推流过程中，通过RTMP 302的方式获取到服务器慢速信息，根据客户端以及服务器端慢速信息，来进行断流重推，快速恢复直播，提高推流成功率。
6. CDN动态调度
用户对直播体验的要求越来越高，要更快地进入直播间，同时兼顾稳定性。传统调度方案存在命中率低、调度耗时高、剔除慢、资源利用率低等问题，不利于实现秒开，也不利于直播的稳定性，需要采用更合适直播场景的调度方案。
直播秒开主要受几方面延时影响：
1. 调度延时，包括HTTPDNS/DNS/302等。
2. 访问延时，包括建链延时、数据下载延时、渲染延时。
3. 回源延时，包括未命中情况下回源调度、建链、数据下载整体延时。
第1点，可以通过客户端后台调度等方法，做到0延时；第2点，可以通过客户端逻辑优化、CDN就近接入大幅降低。
而第3点，由于直播服务的特殊性，需要实时数据，只能通过回源解决。完美解决该问题，需要客户端和服务器共同配合，在确保第1点调度延时不受影响的情况下，快速获取命中率更高的节点，大幅规避回源延时的影响。
目前，传统调度方案使用DNS或HTTPDNS域名解析获得CDN接入点的地址，存在以下几个问题：
• 受限于Local DNS TTL，用户对CDN异常机器被剔除、负载均衡策略调整等情况的感知慢（甚至需要5分钟以上），影响直播稳定性。
• 受限于DNS逻辑IP数量，单地能利用的资源有限，容易产生局部高负载等情况，影响直播稳定性。如下，一次DNS域名解析，只返回了14个IP。
• 不能按流维度进行收敛调度，请求数少的流在CDN边缘的命中率低，导致首帧大、秒开体验差。如下，新调度服务关闭流收敛调度，命中率下降，平均首帧上涨。
HTTPDNS/DNS地址预取解决了调度延时，但是没有解决命中率问题，对秒开体验没有做到最优，所以为了追求极致秒开体验，提出了多流预调度方案。
1. 客户端在启动时、滑动前预取客户接下来将要访问的流信息{M,X,Y,Z}。
2. 将流信息{M,X,Y,Z}通过厂商调度服务接口，获取流的准确地址{A,B,C,D}。
3. 用户最终点击或者访问时，可以直接访问对应地址，如访问流M，直接可以命中A的缓存
本方案使用专门的调度服务负责用户接入调度，用户先请求调度服务预取CDN接入点的地址，再使用该地址访问CDN。该方案有以下几个特点：
• 批量预取。在用户点开直播前先预取调度结果，并且支持一次请求多路流的调度结果。批量预取避免了调度产生额外延迟，有利于秒开体验。
• 流收敛调度。调度服务拥有CDN全部机器列表，能按流进行全局收敛调度，提高命中率，有利于秒开体验。
• 故障快感知、秒级容灾。调度服务拥有CDN全部机器状态信息，能做好全局负载均衡，提高资源利用率，此外，调度服务能快速感知并剔除异常节点，这些有利于直播稳定性。
新方案最大的特点是根据流ID进行调度，提高CDN边缘命中率，优化秒开，符合直播场景的特殊需求。
从下图可以看出使用多流调度接口，对命中率和首帧有明显的改善。下图显示，关闭汇聚功能后，命中率下降。
下图显示，关闭汇聚，平均首帧上涨。
7. 视频编码压缩
7.1 极速高清技术
当码率上升幅度一定时，随着初始码率的提高，码率上升带来的主观感受提升趋于减少，所以当客户端当前播放码率高到一定程度后，尽管网络环境变得更好，也不需要再提升码率级别；服务器端同样不需要编码过高码率的视频，节约服务器资源。
当码率下降幅度一定时，随着初始码率的升高，码率下降带来的主观感受削弱趋于减少，所以一方面服务器端存储的高码率视频的码率级别可以减少，低码率视频的码率级别可以增加；另一方面客户端在当前视频码率已经很低的时候，要尽量避免码率下降。
人眼对于低时间复杂度、高空间复杂度的画面最为敏感，对于低时间复杂度、低空间复杂度的画面最不敏感。对于不敏感的视频，无论是起始码率的变化和码率幅度的变化都不能对主观感知有太大的影响；所以当客户端当前播放的视频是不敏感的视频时，可以更少地进行码率提升操作，节约带宽资源，服务器端对于此类资源也可以不用编出太多的码率级别，节约服务器资源；在低分辨率环境下，人眼对于细节较为精致同时运动剧烈（高空间复杂度、高时间复杂度）的图像的感知有限，码率的大幅上升对于人眼的感知并没有起到太大的帮助；所以当客户端播放此类视频时，也可以减少码率提升操作，服务器端对于此类视频也不用在高码率区间存储太多码率级别。
腾讯云极速高清技术主要思想是把编码bits尽量放在最重要和人眼最关注的地方，通过AI技术，实时识别视频内容的场景，把视频分成游戏、秀场、体育、户外、动漫、美食、影视剧等几大类几十个小类场景分类，画面特征比较明显场景类如游戏、足球、篮球、动漫等纯CNN网络模型，识别准确率98%以上，电视剧、户外运动、美食、旅游等画面特征比较分散帧间运动变化比较大场景CNN结合RNN+LSTM做时域+空域分析，准确率85%左右。
不同场景配置不同直播编码参数，直播编码参数根据视频源码率、帧率、分辨率、纹理和运动变化幅度等情况以及综合机器负载和画质效果，选择最优编码模版参数。根据不同场景分类不同的视频类别，同一个视频里的不同段，应用完全不一样的编码参数；“不同的参数”的概念包括但不限于：IBP帧类型、量化参数QP、分辨率等，支持编码参数按帧实时更新生效。
不管是标准H.264/JVT- G012码率控制算法还是x264的码率控制算法，在运动变化比较明显的场景下，预编一次得到率失真理论凸曲线都是尽可能接近最优失真曲线，国内CDN带宽基本都是按95计费法，CDN带宽采样点是5分种的均值，对于这种运动场景实时检测切换比较明显的场景帧我们在x264码率控制的基础上对于预编得到的QP值和码率会动态向上迅速调整保证画面效果，这种场景切换动态变化大的那几帧对于5分钟带宽均值基本没影响，但画质VMAF得分会有2-3分以上的提高。
针对h264视频编码格式，设计了一种在视频残差的频域上消除噪声的算法。该算法结合了当前编码宏块的残差大小，宏块的QP值，历史的频域值等，并根据不同场景选择匹配的video denoise模板，自适应地进行宏块级的视频处理，能够以极低的CPU消耗对噪声宏块进行优化，同时保留清晰宏块的完整性。
综上所述，腾讯云的极速高清，可以通过上述措施优化后，在视频清晰度不降低的情况下，将视频码率压缩30%左右，节省30%左右的cdn播放带宽，降低了视频对带宽的要求，提升了观众的体验。
7.2 H265代替H264
H.265是ITU-T VCEG继H.264之后所制定的新的视频编码标准。H.265标准围绕着现有的视频编码标准H.264，保留原来的某些技术，同时对一些相关的技术加以改进。新技术使用先进的技术用以改善码流、编码质量、延时和算法复杂度之间的关系，达到最优化设置。具体的研究内容包括：提高压缩效率、提高鲁棒性和错误恢复能力、减少实时的时延、减少信道获取时间和随机接入时延、降低复杂度等。H.264由于算法优化，可以低于1Mbps的速度实现标清（分辨率在1280P*720以下）数字图像传送；H.265则可以实现利用1~2Mbps的传输速度传送720P（分辨率1280*720）普通高清音视频传送。
H.263可以2~4Mbps的传输速度实现标准清晰度广播级数字电视（符合CCIR601、CCIR656标准要求的720*576）；而H.264由于算法优化，可以低于2Mbps的速度实现标清数字图像传送；H.265 High Profile可实现低于1.5Mbps的传输带宽下，实现1080p全高清视频传输。
除了在编解码效率上的提升外，在对网络的适应性方面H.265也有显著提升，可很好运行在Internet等复杂网络条件下。
在运动预测方面，下一代算法将不再沿袭“宏块”的画面分割方法，而可能采用面向对象的方法，直接辨别画面中的运动主体。在变换方面，下一代算法可能不再沿袭基于傅立叶变换的算法族，有很多文章在讨论，其中提请大家注意所谓的“超完备变换”，主要特点是：其MxN的变换矩阵中，M大于N，甚至远大于N，变换后得到的向量虽然比较大，但其中的0元素很多，经过后面的熵编码压缩后，就能得到压缩率较高的信息流。
关于运算量，H.264的压缩效率比MPEG-2提高了1倍多，其代价是计算量提高了至少4倍，导致高清编码需要100GOPS的峰值计算能力。尽管如此，仍有可能使用2013年的主流IC工艺和普通设计技术，设计出达到上述能力的专用硬件电路，且使其批量生产成本维持在原有水平。5年（或许更久）以后，新的技术被接受为标准，其压缩效率应该比H.264至少提高1倍，估计对于计算量的需求仍然会增加4倍以上。随着半导体技术的快速进步，相信届时实现新技术的专用芯片的批量生产成本应该不会有显著提高。因此，500GOPS，或许是新一代技术对于计算能力的需求上限。
在实际应用场景下，在相同的画质情况下，可以节省30%左右码率，目前市场上主要的直播厂商都有使用H265来进行质量和成本优化。
7.3 AV1
AV1是一种新兴的开源、版权免费的视频压缩格式，由开放媒体联盟(AOMedia)行业联盟于2018年初联合开发并最终定稿。AV1开发的主要目标是在当前的编解码器基础上获得可观的压缩率提升，同时确保解码的复杂性和硬件的实际可行性。本文简要介绍了AV1中的关键编码技术，并与VP9和HEVC进行了初步的压缩性能比较。
AV1开发的着重点包括但不限于以下目标:一致的高质量实时视频传输、对各种带宽的智能设备的兼容性、易处理的计算占用空间、对硬件的优化以及对商业和非商业内容的灵活性。编解码器最初使用的是VP9工具和增强功能，然后AOMedia的编解码器、硬件和测试工作组被提出、测试、讨论和迭代产生新的编码工具。到今天为止，AV1代码库已经到了最后的bug修复阶段，并且已经合并了各种新的压缩工具，以及为特定用例设计的高级语法和并行化特性。本文将介绍AV1中的关键编码工具，与同等质量的高性能libvpx VP9编码器相比，AV1的平均比特率降低了近30%。
AV1相对于H265的优点有两个，第一个是AV1是开源的，没有版权的限制，H265有版权的限制，容易引起版权纠纷。第二个是AV1的压缩率在不断的优化中，压缩效果已经超过了H265，并已经于H265拉开了一定的距离。
8. 协议优化
针对音视频场景，对底层网络协议拥塞控制算法，以及重传丢包算法进行优化。
8.1 TCP优化：
我们也会通过一些算法补充，尽可能充分地利用现有流量。例如在600kb的网络带宽下丢包率较低而延迟可控，那么通过一些高质量算法我可以把600kb的上限提升到800～900kb的水平，其优化效果也显而易见。比如典型的方法是FEC与ARQ。
FEC最初来源于光纤层面的算法优化，例如这里我需要传输10个数据包，一旦出现一个包丢失的情况，接收端会重新寻求该包，这其中就有一个包的损失。因此FEC采取了一个补偿方法，若需发送10个数据包，则发送端会多发一个数据包，该数据包根据前面10个数据包通过FEC算法算出，接收端实际上只需成功接收到11个包中任意10个包即可把原数据流重新组装出来。在这种模式下如果控制丢包率在10%以下，实际上是不需要做任何重传请求的，因此丢包率在10%以下的延迟基本上没有什么影响。当然这里存在一个10%的额外带宽消耗，如果在一些网络下丢包率较高而带宽没有问题的话，那么FEC会把丢包重传带来的损失降低，继而把延迟损失降低到最小。
ARQ则是接收端在侦测到丢包时自动发送重传请求，例如发送端发送十个数据包：1、2、3、4、5、6、7、8、9、10；而接收端在依次收到1、2、3、4、5、6、8、10后未收到7、9，随后接收端会向发送端发送一个重传请求，请求发送端再次发送7与9，随后发送端会重新打包7和9并发送到对端。ARQ是一个很常见的重传算法，该重传算法也存在连续型ARQ与不连续型ARQ，ARQ与FEC可以相互配合。如果网络带宽不错但延迟比较明显，我们会优先使用FEC，且控制丢包率在20%以内；如果丢包率超过20%，使用FEC会额外消耗更多的带宽，继而导致整个传输链路的持续恶化。一般情况下在丢包率超过20%，甚至达到10%时， 控制降低FEC算法的权重，并进一步使用ARQ能够带来更加出色的优化效果。
除了FEC与ARQ，还有一种被称为PacedSender的算法。在视频通信中，传输存在峰值与低谷，单帧视频可能有上百KB，我们知道视频当中存在I帧与B帧，一般情况下I帧出现时，代表着达到一个流量高峰；而B帧则是一个很小的片段，这就造成整个传输的抖动非常严重。如果是当视频帧被编码器编码出来后，就立即进行打包发送，瞬间会发送大量的数据到网络上，这可能会引起网络衰减和通信恶化。WebRTC引入pacer，pacer会根据estimator评估出来的码率，按照最小单位时间（5ms）做时间分片进行递进发送数据，避免瞬时对网络的冲击。pacer的目的就是让视频数据按照评估码率均匀的分布在各个时间片里发送，所以在弱网的WiFi环境，pacer是个非常重要的步骤，其可通过拉长时间，使得整个发送的抖动情况趋于平缓。
以上三个算法可有效提升弱网环境下的传输效率并降低丢包率。也许有些人会提到SRT，SRT不是一个算法而是一个开源的包，实际上是内置了FEC、ARQ等算法，通过UDP+FEC+ARQ来模拟TCP的算法。TCP严格遵循质量优先策略，不允许丢失任何一个数据帧，一旦丢包超过限度就会中断链路，而这对音视频的应用场景来说有些过于严苛。相对而言，基于UDP的SRT则更加适合音视频应用场景。我们知道最近业界有不少公司都开始测试 SRT算法，目前来看效果还是非常不错的。
TCP协议使用BBR优化网络传输
BBR全称Bottleneck Bandwidth and RTT，它是谷歌在2016年推出的全新的网络拥塞控制算法。要说明BBR算法，就不能不提TCP拥塞算法。
传统的TCP拥塞控制算法，是基于丢包反馈的协议。基于丢包反馈的协议是一种被动式的拥塞控制机制，其依据网络中的丢包事件来做网络拥塞判断。即便网络中的负载很高时，只要没有产生拥塞丢包，协议就不会主动降低自己的发送速度。
TCP在发送端维护一个拥塞窗口cwnd，通过cwnd来控制发送量。采用AIMD，就是加性递增和乘性递减的方式控制cwnd，在拥塞避免阶段加性增窗，发生丢包则乘性减窗。
这个拥塞控制算法的假定是丢包都是拥塞造成的。
TCP拥塞控制协议希望最大程度的利用网络剩余带宽，提高吞吐量。然而，由于基于丢包反馈协议在网络近饱和状态下所表现出来的侵略性，一方面大大提高了网络的带宽利用率；但另一方面，对于基于丢包反馈的拥塞控制协议来说，大大提高网络利用率同时意味着下一次拥塞丢包事件为期不远了，所以这些协议在提高网络带宽利用率的同时也间接加大了网络的丢包率，造成整个网络的抖动性加剧。
TCP拥塞控制算法的假定是丢包都是拥塞造成的，而事实上，丢包并不总是拥塞导致，丢包可能原因是多方面，比如：路由器策略导致的丢包，WIFI信号干扰导致的错误包，信号的信噪比（SNR）的影响等等。这些丢包并不是网络拥塞造成的，但是却会造成TCP 控制算法的大幅波动，即使在网络带宽很好的情况下，仍然会出现发送速率上不去的情况。比如长肥管道，带宽很高，RTT很大。管道中随机丢包的可能性很大，这就会造成TCP的发送速度起不来。
Google 的BBR出现很好的解决了这个问题。BBR是一种基于带宽和延迟反馈的拥塞控制算法。它是一个典型的封闭反馈系统，发送多少报文和用多快的速度发送这些报文都是每次反馈中不断调节。
BBR算法的核心就是找到两个参数，最大带宽和最小延时。最大带宽和最小延时的乘积就是BDP(Bandwidth Delay Product), BDP就是网络链路中可以存放数据的最大容量。知道了BDP就可以解决应该发送多少数据的问题，而网络最大带宽可以解决用多大速度发送的问题。如果网络比作一条高速公路，把数据比作汽车，最大带宽就是每分钟允许通行的汽车数量，最小RTT就是没有拥堵情况下，汽车跑一个来回需要的时间，而BDP就是在这条路上排满汽车的数量。
BBR如何探测最大带宽和最小延时
BBR是如何探测最大带宽和最小延时呢？首先有一点就是最大带宽和最小延时是无法同时得到的。
如图所示，横轴是网络链路中的数据量，纵轴分别是RTT和带宽。可以发现在RTT不变的时候，带宽一直在上升，没有达到最大，因为这个时候网络没有拥塞，而带宽停止上涨的时候RTT持续变大，一直到发生丢包。因为这个时候，网络开始拥塞，报文累积在路由器的buffer中，这样延时持续变大，而带宽不会变大。图中BDP的竖线所标识的就是理想情况下最大带宽和最小延时。很明显，要找到BDP, 很难在同一时刻找到最小的RTT和最大带宽。这样最小RTT和最大带宽必须分别探测。
探测最大带宽的方法就是尽量多发数据，把网络中的buffer占满，带宽在一段时间内不会增加，这样可以得到此时的最大带宽。
探测最小RTT的方法就是尽量把buffer腾空，让数据交付延时尽量低。
由此，BBR就引入了基于不同探测阶段的状态机。
状态机分为4个阶段，Startup，Drain，ProbeBW， ProbeRTT。
Startup类似于普通拥塞控制里的慢启动，增益系数是 2ln2，每一个来回都以这个系数增大发包速率，估测到带宽满了就进入 Drain状态，连续三个来回，测得的最大瓶颈带宽没有比上一轮增大 25%以上，就算带宽满了。
进入 Drain状态，增益系数小于 1，也就降速了。一个包来回，把 Startup状态中产生的拍队排空，怎样才算队列空了？发出去还没有 ACK 的数据包量 inflight，与 BDP 进行比较，inflight < BDP 说明空了，道路不那么满了，如果 inflght > BDP 说明还不能到下一个状态，继续 Drain。
ProbeBW是稳定状态，这时已经测出来一个最大瓶颈带宽，而且尽量不会产生排队现象。之后的每个来回，在 ProbeBW状态循环（除非要进入下面提到的 ProbeRTT状态），轮询下面这些增益系数，[5/4, 3/4, 1, 1, 1, 1, 1, 1]，如此，最大瓶颈带宽就会在其停止增长的地方上下徘徊。大部分时间都应该处于 ProbeBW状态。
前面三种状态，都可能进入 ProbeRTT状态。超过十秒没有估测到更小的 RTT 值，这时进入 ProbeRTT状态，把发包量降低，空出道路来比较准确得测一个 RTT 值，至少 200ms 或一个包的来回之后退出这个状态。检查带宽是否是满的，进入不同的状态：如果不满，进入 Startup状态，如果满，进入 ProbeBW状态。
BBR算法不会因为一次或者偶然的丢包就大幅降低吞吐量，这样就比TCP就有较强的抗丢包能力。
如图所示，cubic在丢包率上升的时候，吞吐量下降很快。而BBR在5%以上的丢包才会出现明显的吞吐量下降。
BBR与基于丢包反馈的cubic和基于延时反馈的vegas算法的本质区别在于，BBR无视随机丢包，无视时延短暂波动，采用了实时采集并保留时间窗口的策略，保持对可用带宽的准确探知。事实上，丢包并不一定会造成带宽减少，延迟增加也不一定会造成带宽减少，cubic无法判断是否拥塞造成的丢包，vegas对延时增加过于敏感，会导致竞争性不足。
BBR可以区分出噪声丢包和拥塞丢包，这样意味着，BBR比传统TCP拥塞控制算法具有更好的抗丢包能力。
BBR在实时音视频领域的应用
实时音视频系统要求低延时，流畅性好，而实际网络状态却是复杂多变的，丢包，延时和网络带宽都在时刻变化，这就对网络拥塞控制算法提出了很高的要求。它需要一种带宽估计准确，抗丢包和抖动能力好的拥塞控制算法。
目前Google的webrtc提供了GCC控制算法，它是一种发送侧基于延迟和丢包的控制算法，这个算法的原理在很多地方都有详细描述，这里不再赘述。GCC用于实音视频的主要问题还在于在带宽发生变化时，它的带宽跟踪时间比较长，这样就会造成带宽突变的时候无法及时准确探测带宽，可能造成音视频卡顿。
既然BBR有良好的抗丢包能力，自然也被想到应用到实时音视频领域。但是，BBR并不是为处理实时音视频设计的，所以需要对一些问题做一些优化。
第一，BBR在丢包率达到25%以上，吞吐量会断崖式下降。
这是由BBR算法的pacing_gain数组[5/4, 3/4, 1, 1, 1, 1, 1, 1]的固定参数决定的。
在pacing_gain数组中，其增益周期的倍数为5/4，增益也就是25%，可以简单理解为，在增益周期，BBR可以多发送25%的数据。
在增益期，丢包率是否抵消了增益比25%？也就是说，x是否大于25。
假设丢包率固定为25%，那么，在增益周期，25%的增益完全被25%的丢包所抵消，相当于没有收益，接下来到了排空周期，由于丢包率不变，又会减少了25%的发送数据，同时丢包率依然是25%...再接下来的6个RTT，持续保持25%的丢包率，而发送率却仅仅基于反馈，即每次递减25%，我们可以看到，在pacing_gain标识的所有8周期，数据的发送量是只减不增的，并且会一直持续下去，这样就会断崖式下跌。
怎样才能对抗丢包，这就需要在每个周期考虑丢包率，把丢包率补偿进去。比如丢包率达到25%的时候，增益系数就变成50%，这样就可以避免由于丢包带来的反馈减损，然而，你又如何判断这些丢包是噪声丢包还是拥塞丢包呢？答案在于RTT，只要时间窗口内的RTT不增加，那么丢包就不是拥塞导致的。
第二，BBR的最小RTT有个10s超时时间，在10s超时后，进入ProbeRTT 状态，并持续最小200ms，此状态下，为了排空拥塞，inflight只允许有4个包，这会导致音视频数据在这段时间内堆积在发送队列中，使得时延增加。
可行的解决办法是，不再保留ProbeRTT状态，采用多轮下降的方式排空拥塞，然后采样最小RTT，也就是在infight > bdp的时候，设置pacing gain为0.75，用0.75倍带宽作为发送速率，持续多轮，直到inflight < bdp, 此外，最小RTT的超时时间改成2.5s，也就是说不采用非常激进的探测方式，避免了发送速率的大幅波动，可以改善探测新的带宽过程中发送队列中产生的延时。
第三，开始提到pacing gain数组上探周期为1.25倍带宽，随后是0.75倍带宽周期，这两个RTT周期之间会出现发送速率的剧烈下降，这可能会使音视频数据滞留在buffer中发不出去，引入不必要的延时。
解决办法可以考虑减小上探周期和排空周期的幅度，比如使用[1.1 0.9 1 1 1 1 1 1]这种pacing gain参数，这样做的优点就是可以保证媒体流的平稳发送，发送速率不会大幅波动，缺点是，网络带宽改善的时候，上探时间会变长。
第四，BBR探测新带宽收敛慢的问题
原始的BBR算法的收敛性受到pacing gain周期影响，带宽突降的时候，BBR需要多个轮次才会降到实际带宽。这是由于BBR每轮只能降速一次，而pacing gain的6个RTT的保持周期大大加长了这个时间。解决的办法就是随机化pacing gain的6个保持周期，如果是0.75倍周期，就一次降速到位，这样可以极大的减少BBR的收敛时间。
最后，BBR算法看似简单，但是应用到实时音视频却没有那么简单，需要大量的实验优化，谷歌也在webrtc中引入BBR，目前仍在测试中。本文提到的改进方法是网易云信在这方面的一些尝试，希望能够抛砖引玉，有更多有兴趣的人能够为BBR应用到实时音视频领域出力
https://zhuanlan.zhihu.com/p/63888741
大RTT场景首帧优化
众所周知，tcp的拥塞控制算法包含了慢启动、拥塞避免、拥塞发生和快速重传等算法。其中慢启动一般是指连接建好的开始先初始化拥塞窗口cwnd大小为1，表明可以传一个MSS大小的数据。每当收到一个ACK，cwnd大小加一，呈线性上升。 每当过了一个往返延迟时间RTT(Round-Trip Time)，cwnd大小直接翻倍，乘以2，呈指数上升。
其实慢启动的过程是tcp在探测当前网络的承受能力，以免直接扰乱了网络通道的秩序。从公平性而言，这个是做法是合理的。并且在RTT较小，比如<20ms的链路上，发包速率也能得到快速提升，不影响传输效率。
然而在RTT > 100ms的链路上，问题就变得比较复杂了。我们以一个case为例说明：比如在巴西用户访问美国cdn节点这种情况，RTT大致120ms左右。我们测试一个优化前的case：
收到第一个IDR帧数据量152k左右，码率比较高，耗时654ms。
分析抓包看：
由于RTT 120ms过大，速度增长周期过于缓慢。详细分析，TCP协议栈默认首个窗口大小10个MSS。比如，152k的数据大致106个MSS，大致需要4、5个RTT才能将数据完全发出去。
修改默认10个MSS为40个，加快窗口增长速度。
具体修改点：tcp_init_cwnd(),宏TCP_INIT_CWND，sysctl参数，自己在内核中增加一个控制initcwnd的proc参数，该方式对于所有tcp连接有效；
同样的环境，184k的数据只需要492ms，首帧降低了160ms左右，优化了24.4%。
自适应窗口调整优化：
如果仅仅优化起始窗口大小，那必定是固定值，不利于和直播流码率以及不同客户端配合优化，所以我们提出了一种进阶方案，假设新增了动态的proc参数init_win_size：
1、收集客户端ip维度的bw（历史带宽值），用于评估新连接的带宽。
2、实时跟新每个流的首帧大小first_I_size。
来了一个新的请求后，
if(命中bw)
if(bw >= first_I_size)
init_win_size = first_I_size/MSS
else
init_win_size = bw/MSS
else //没有命中历史bw
init_win_size = 48 //大盘历史数据正态分布统计值
从大盘数据看自适应在默认值48的基础上还能优化5%。
采用fastopen回源实现0RTT
各个直播平台主播开播的门槛非常低，存在大量的没有人气的主播，产生优质内容的主播同时也非常少。主要流量都集中在头部5%～10%的直播房间，因此存在大量比例的冷门房间，观看人数非常少。
不少的cdn或者源站，都是多层的，层级之前的数据传输大部分都是采用外网的。为了降低内部数据传输的损耗，在没有观众观看的情况下，边缘和中间层都会停止拉流，只有在中心节点有直播流数据。当有观众过来观看，会逐级向上回源。每一层级都会重新创建新的回源连接。tcp连接建立阶段至少是1+RTT，多级建立连接，累计起来，耗费的时间会比较客观。
为了减少回源耗时，建议在tcp连接建立的时候，开启tcp fastopen。
下图是正常连接建立，以及发起http get的请求。在ack的时候，发起http get请求，耗时1RTT+。
下图是开启tcp FastOpen，可以做到0RTT。大大降低了建立连接的时间。
在客户端首次建立连接时的过程：
1、客户端发送 SYN 报文，该报文包含 Fast Open 选项，且该选项的 Cookie 为空，这表明客户端请求 Fast Open Cookie；
2、支持 TCP Fast Open 的服务器生成 Cookie，并将其置于 SYN-ACK 数据包中的 Fast Open 选项以发回客户端；
客户端收到 SYN-ACK 后，本地缓存 Fast Open 选项中的 Cookie。
所以，第一次发起 HTTP GET 请求的时候，还是需要正常的三次握手流程。
之后，如果客户端再次向服务器建立连接时的过程：
1、客户端发送 SYN 报文，该报文包含「数据」（对于非 TFO 的普通 TCP 握手过程，SYN 报文中不包含「数据」）以及此前记录的 Cookie；
2、支持 TCP Fast Open 的服务器会对收到 Cookie 进行校验：如果 Cookie 有效，服务器将在 SYN-ACK 报文中对 SYN 和「数据」进行确认，服务器随后将「数据」递送至相应的应用程序；如果 Cookie 无效，服务器将丢弃 SYN 报文中包含的「数据」，且其随后发出的 SYN-ACK 报文将只确认 SYN 的对应序列号；
3、如果服务器接受了 SYN 报文中的「数据」，服务器可在握手完成之前发送「数据」，这就减少了握手带来的 1 个 RTT 的时间消耗；
4、客户端将发送 ACK 确认服务器发回的 SYN 以及「数据」，但如果客户端在初始的 SYN 报文中发送的「数据」没有被确认，则客户端将重新发送「数据」；
5、此后的 TCP 连接的数据传输过程和非 TFO 的正常情况一致。
所以，之后发起 HTTP GET 请求的时候，可以绕过三次握手，这就减少了握手带来的 1 个 RTT 的时间消耗。
tcp fastopen相对于quic，不需要进行额外的开发和适配，复用现有的架构，就可以实现0RTT。
按照3层回源来，服务器之间的RTT约为20ms，冷流的场景下，可以减少约40ms延迟。服务器集群一般都是跨地域的，优化效果会更明显一些。
8.2 UDP改造：
UDP概括起来就是一个”发送后不管的”的协议。它是无状态的，没有拥赛控制或可靠的传输支持，这也导致了网络运营商会针对UDP协议的限流。UDP属于应用层协议，可以结合音视频的特点，在应用层对拥塞控制和重传算法进行场景性的优化。
Quic协议
QUIC是谷歌制定的一种基于UDP的低延迟的互联网传输层协议。TCP/IP协议族是互联网的基础，其中传输层协议主要包括TCP和UDP协议。与TCP协议相比，UDP更为轻量，但是错误校验也要少得多。这意味着UDP效率更高，但是可靠性比不上TCP。
QUIC作为新的传输层协议，很好地解决了TCP和UDP各个的缺点。它融合了包括TCP、TLS、HTTP/2等协议的特性，但基于UDP传输。QUIC的一个主要目标就是减少连接延迟。
QUIC底层的传输是基于UDP的，所以对UDP进行性能优化可以直接影响QUIC的传输性能。
QUIC设计目的是对HTTP/2语法的优化，设计时HTTP/2作为主要的应用层协议，quic提供了等效HTTP/2的多路复用以及流控，等效于TLS的安全传输，可靠，以及TCP的拥塞控制quic作用于用户空间，现在chrome已经内置了quic的支持，因为quic是用户空间的基于UDP的传输层协议，quic更新时不会受到因为各种设备或中间设备对于新的传输层协议不支持、或者升级缓慢的影响。
QUIC在功能上等同于 TCP + TLS + HTTP/2, 但是基于 UDP 之上。 QUIC 对比 TCP + TLS + HTTP/2 的优势有：
1、减少了 TCP 三次握手及 TLS 握手时间。— 减少tcp建立连接的时间，正常的tcp建立链接，需要1.5个RTT，才能进行数据传输。
2、改进的拥塞控制。— 灵活更新tcp拥塞控制算法，进行拥塞控制调优
3、避免队头阻塞的多路复用。— 只针对http并行请求有用
4、连接迁移。 — 通过connection-id来区分链接，弱网情况下，不需要重连
5、前向冗余纠错。
适用场景：
1、长距离传输，即RTT较大的，长肥管道，国外的网络比较常见，改善效果比较明显。
2、手机网络，频繁的切换网络，且网络状况比较复杂，抖动比较频繁。3、请求的页面资源数较多，并发的连接数多，对比较复杂的网站，改善效果较好。
4、需要加密传输。QUIC原生版本，是为了改善https的性能，优化版本都是基于https的，因此如果数据需要加密，可以直接使用，不需要进行适配处理。
音视频场景与普通网站请求有较大的差别，存在比较明显的特点，具体如下：
1. 需要传输的数据量大，比普通的网页文本，需要的带宽大很多。
2. 内容信息重要性低，不需要加密。
3. 主要的应用场景，一个终端或者用户只观看一个视频，并发的连接几乎没有。
4. 通过cdn加速后，服务器与用户距离非常近，RTT都非常小。
国内的视频直播主要都是采用的http协议，占比超过90%。移动端基本上都是采用http，web端有些浏览器有强制要求，会使用一些https。
国内各个直播平台，国内都有尝试过使用quic，改善效果不明显。由于国外由于网络传输RTT较大，因此有较明显的改善。
CDN不能简单的使用QUIC，需要做一些修改和改进，才能实现优化效果，具体如下：
1. 服务端跨机器共享配置信息，提升0RTT比例，经过这个优化后，0RTT的比例可以提升到90%以上。
2. 提升加解密性能，减少加解密导致的性能损耗。
3. 使用BBR等性能比较好的拥塞控制算法。
4. 剥离加密逻辑，提供免加解密版本的quic。
目前使用QUIC的方式都是在不改变业务逻辑的场景下，对网络进行加速，如推流采用rtmp over quic，播放采用http+flv over quic，或者http+hls over quic等。
目前市场上主要使用quic解决最后一公里的问题，即直播的拉流播放问题，QUIC在20%丢包率场景下，可以保持稳定传输。
QUIC更像是一个完成版的TCP。据Google透露，使用了QUIC后，YouTube的rebuffer率降低最多达18%。
SRT协议
SRT是基于UDT的传输协议，保留了UDT的核心思想和机制，抗丢包能力较强。近几年大家可以感受到，现在随着技术发展，RTMP协议表现得越发力不从心，不仅将近10年都没有更新，连各大视频网站都在今年禁播RTMP协议视频流，在此背景下，我们发现SRT或许是一条更可靠的出路。
SRT保留了UDT，主要表现就是低延迟和抗丢包能力上的提升，在音视频这种看重实时性的领域，SRT基于时间的报文发送，使其具有良好的防止流量突发的能力。SRT对上层提供了丰富的拥塞控制统计信息，包括RTT、丢包率、inflight、send/receive bitrate等。利用这些丰富的信息，我们可以实现带宽预测，并根据带宽的变化在编码层去做自适应动态编码与拥塞控制。
在我们支持RTMP协议视频流传输的EasyDSS平台，不会出现丢包的情况，但当网络状态差时，服务器会将包缓存起来，导致累积的延迟，延迟时间一般在几秒，这是RTMP协议的通病；然而在通过SRT协议传输时，由于采用了UDP传输方式，并使用ARQ的丢包恢复机制，基于公网的传输延迟级别一般可控制在1s以内。
低延迟并不代表着视频播放的低质量，SRT的传输和纠错机制可以最大化利用可用带宽并排除网络错误和干扰，因此可以在同等网络环境下传输更高码率的视频流，配合H.264和HEVC等高效编码格式，能够在不良的网络状况下依然保证视频的高质量。
SRT主要是采用了比较激进的丢包重传算法，通过冗余数据的方式，减少了网络抖动对发送数据的影响。目前主要是用在视频传输的第一公里上，即使用SRT改善推流质量。SRT适合点到点流媒体传输，大主播质量保证，移动直播。目前很多大客户已经在不同规模的应用SRT。从上行卡顿率数据看到，卡顿率有明显的改善。腾讯云音视频也在一些重大的电竞赛事中使用SRT作为上行推流。从下图可以看出，在使用 SRT 推流后，可以明显的看到卡顿率有所改善。而目前传统rtmp推流方式在5%丢包率场景下已无法稳定传输。
SRT相比QUIC重传率更高，但抗丢包性更好；网络层50%丢包下，SRT仍可保证稳定可靠传输。下图展示的是同一链路同一直播文件，每5分钟提高5%丢包率的场景下，推流质量情况。Rtmp over srt推流帧率更平稳。
目前腾讯云已经支持了rtmp over srt，腾讯云音视频将SRT作为传输层之上的协议，可以将任何基于tcp的应用层协议改造为基于SRT的应用层协议。腾讯云还支持ts over SRT推流。通过SRT直接传输包含音视频数据的ts流，下行复用现有直播系统。TS over SRT已作为Haivision硬件及OBS的推流格式标准。
WebRTC协议
WebRTC，名称源自网页即时通信（Web Real-Time Communication）的缩写，浏览器不需要服务器的中转，可以直接通信。
WebRTC优点：
提供低延迟、高质量的实时音视频通信；
一套端上的流媒体框架，音视频处理全套能力，并且具有跨平台特性；
提供了一套标准的API（被纳入W3C推荐标准），Web应用开发人员可以基于这套API实现丰富的实时音视频应用。
WebRTC还有一个优势是其他音视频解决方案无法达到的，就是它已经集成到浏览器中，无安装、无插件。
多协议推流平台在原有直播架构基础上，对WebRTC进行改造能直接接收WebRTC推流。标准WebRTC由于不支持H.265音视频编码格式不支持B帧编码，已经无法满足国内直播行业需求，多协议推流平台对WebRTC进行了优化与升级改造，以达到高兼容、低成本、大容量的低延时直播要求。主要优化点如下：
WebRTC是基于SDP进行能力协商的，为了更好的支持新功能新特性，同时兼容标准WebRTC，多协议推流平台对WebRTC扩展的SDP定义和协商进行了规范。
支持H265，腾讯云音视频支持添加H.265相关信息，并实现H.265的RTP拆包、解析、组帧和解码等功能模块。
支持B帧。通过终端SDK在offer sdp中添加B帧相关信息，实现B帧timestamp非单调递增的处理逻辑，后台实现相应B帧timestamp封装逻辑。
非加密传输。标准WebRTC原本的设计使用场景是音视频通信，所以加密是必选项。而在直播应用中很多场景是公开的，没有必要采用加密传输，去掉加密既可以省去开播时DTLS握手产生的延时，也可以减少后台和前端加解密的开销。
此外，多协议推流平台的WebRTC还针对场景做了可配置的容错特性，主要根据音视频编码的特点并结合业务场景，例如将传输的报文分了多个优先级，在需要主动丢包的情况下优先丢弃低优先级的数据(如B帧，音频等)。
目前所有协议里面，延迟最低的，可以做到实时，它原本就是用来实现视频聊天功能的，因为它使用了P2P技术，可以使客户端直接互相连接，不需要通过服务器转发音视频。
webrtc设计的初衷是解决两人，多人的实时音视频通话，所以交互性，实时性很强。可以做到不依赖于服务器的中转。
而我们现在的直播服务大部分的情况下是一对多的通信，也没有那么严格的实时性需求。一个主播可能会有成千上万个接收端，这种方式用传统的P2P来实现是不可能的，所以目前直播的方案基本上都是会有直播服务器来做管理，主播的数据首先发送给直播服务器（推流），直播服务器为了能够支持非常多用户的同事观看，还要通过边缘节点CDN的方式来做地域加速（拉流），所有的接收端都不会直接连接主播，而是从服务器上接收数据。
但是webrtc内部的一些技术模块是非常适合解决直播过程中存在的一些问题，如音视频数据的收发、音频处理回音，语音增强，消除降噪等等。
从大规模分发的角度而言，webRTC 目前难以与 HLS、DASH之类的协议抗衡，一个技术，如同我们日常见到的大多数事务一样，其使用有其优点，但更需要知道其限制。
腾讯快直播方案，是利用webRTC协议的低延迟性、标准性和跨平台性，经由腾讯云WebRTC Server，从腾讯云直播平台拉取直播流。并以WebRtc下发流，且信令服务没有房间逻辑，适合单流纯收看的场景。
由于快直播使用了自己的SDK，因此服务器与SDK可以进行联动，可以精准控制发包速率，进行平滑发送，防止因为突发导致丢包。可以进行灵活的丢包策略，在对抗网络抖动性上，有更好表现。
总结
采用UDP进行音视频数据传输，相对于TCP有以下优势：
1. 优化建立连接过程，复用建立连接配置信息，实现0RTT。
2. 基于UDP能更好的感知网络拥塞情况，优化拥塞控制算法和重传算法，实现更精准的RTT和带宽评估算法。
3. 连接复用，切换网络时，不用重新建立连接。
4. 基于UDP实现的网络协议都是应用层的，可以更好的升级，跨平台性也更好。
5. 使用前向冗余纠错。
但UDP相对于TCP也有些不足，目前的网络中间链路针对TCP做了很多优化，对TCP更友好，对UDP的适配性没有那么好，有些网络设备会限制UDP报文的发送和接受，超过一定的量级，会主动丢弃。
基于UDP的视频传输方案，是需要播放器和cdn配合进行优化，才有改善。目前主要在一些特定的场景使用。
下表列出了目前市场上主要使用的流媒体协议，SRT，QUIC和webRTC都有自己的优点，以及对应的应用场景。
除了市面上比较流行的音视频UDP传输方案，各直播厂商也推出自己的私有解决方案，其中腾讯的TRTC是使用比较广泛的SaaS解决方案，在腾讯会议，企业微信，小红书，陌陌等产品有广泛的使用。
具体实践
腾讯云极速高清产品
https://cloud.tencent.com/document/product/1183
腾讯云AV1产品
https://cloud.tencent.com/developer/article/1875258
腾讯云快直播产品
https://cloud.tencent.com/document/product/267/44249
腾讯云TRTC产品
https://cloud.tencent.com/product/trtc
腾讯云SRT产品
https://cloud.tencent.com/document/product/267/53955
腾讯云GAAP加速产品
https://cloud.tencent.com/document/product/608
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
腾讯云开发者
