大厂技术博客学习|大厂技术博客学习（2）——5G时代下淘宝直播高清低延时技术jie秘云计算|腾讯云

5G时代下淘宝直播高清低延时技术揭秘 - 知乎
csdn现在特殊字符监测很要命哦，汉语拼英要熟练哦~
我们之前也说过斗鱼平台光一个季度在带宽和流量上花费超过1.8亿，其实还有一点没有说，就是我觉得之所以以斗鱼战旗虎牙为代表的二代直播平台没有在三代直播平台中杀出重围的一大原因，就是在移动端的战略眼光，这也是抖音杀出重围的关键因素，当然现在腾讯通过游戏版权long断和移动端流量的布局，本想促成斗鱼虎牙合并，这也是理所应当，毕竟二代直播优势在下降，主播红利在过期，但不可否认的是，从互联网业务来看，移动端业务和流量是抖音在国内外都能杀出重围的关键。
所以这里我们想要看的说白了，也是过期技术，过期不代表没有技术，但是互联网是行业红利期很明显的一个行业，蓝海和红海差别不是一点半点，所以要说明的是学没问题，学思路没问题，学技术没问题，但是如果未来你以产品和技术的角度去看待一个互联网产品，一定要有战略眼光，一定要理念先行，技术是伴随着产品的发展而发展，如果技术迭代提前于产品眼光，那就是马斯克，这是所有做技术的要追求的目标，这才是所有做技术的应该追求的目标，理念先行，思想先行。
书归正传。
基本视频相关技术已经讲过，看看tb是怎么干的
以下摘抄仅学习，没有其他目的：
5G将对视频分辨率和清晰度提出越来越高的要求。淘宝作为一个数亿级用户的短视频与直播平台，业务多样，两端用户分布广，设备和网络情况复杂，给多媒体内容存储和分发带来巨大挑战。在内容生产过程中把控好质量和成本，在内容分发和消费过程中确保用户体验，是当前面临的主要问题。为了解决这个问题, 我们有两个优化目标：
一是在画质不变的前提下降码率
二是在码率不变的前提下提升画面质量。
※ 这就是流媒体优化的思想，你细品
一、概况：在降码率上，我们自研高效编码器，升级播放架构，添加智能ROI, 场景编码，智能码控等工具，有效地降低了视频码率带宽。在这些技术中，高效的编码器能够在质量不变的前提下显著降低码率；场景编码能够根据不同的画面内容配置合适的编码参数；ROI挑出画面中人眼比较关注的区域交给编码器重点编码；智能码控根据人眼主观特性，消除因为超过人眼阈值而浪费的码字。
※ 编码我们提过，H265，H264，但是能影响生态的也只有一线hlw公司也只有他们有能力这么做，二线的让你去开发，也没人用，总体思想，压缩编码优化，优化提升压缩比

在画质上，我们使用前处理增强，去噪，超分高动态范围等算法提高生产内容的观感质量；在体验优化上，通过低延时编码技术，在降低了编码延迟的同时损失很小的码率，增加观众和主播的体验。
※ 估计是GOP关键帧位置的优化，总体思想，图片编码优化

围绕着提高问题发现、问题处理效率的出发点，具备数据采集、存储、异常事件收集、智能告警、告警数据运营、可编码诊断平台、故障自动化处理、变更联动等能力。我们搭建了一套基于淘宝直播的全链路监控体系，从音频，视频，网络这三个方面入手去解决目前淘宝直播全链路的现有问题以及将来可能出现的问题。不断去优化整套高画质低延时系统。
※ 监控，最后看都可以，不重要

与此同时，我们建立了客观质量和主观质量评价体系，采用vmaf，psnr，ssim这一系列的指标作为客观质量评价。针对海量无源场景，我们还基于cnn建立了无源评价模型，保证无源场景下质量评价的准确性。以这些有效的评价手段来确保“画质不变”，并监控线上视频质量。
※ 评价，最后看都可以，不重要，不过这里可以说一句，就是对于技术而言，监控和评价，是后期提升整个系统的量化标准，思想格局打开，也不错
二、视频编码优化——Ali265 往下就比较硬核，我只拿重点说，原文废话省略
2.1.1 码率控制
Ali265是淘宝自研的高性能H.265编码器，对比业界开源的X265可实现BDrate20%以上的增益，对比X264则有40%以上的增益。目前已在淘宝直播，优酷视频，阿里郎会议，VMate，UC云盘等业务中上线使用。

文章图片

S265编码从码率控制, 编码工具两个方向优化编码质量，并从快速算法，工程算法两方面引入速度优化算法。
※ RC=ABR是码率控制的方式，你可以理解为码率比较平均的方式，复杂画面码率低，复杂画面码率高，维持较为合理的平均码率，这种方式。当然实验室数据都是有特定条件的。打个七七八折也很正常
【大厂技术博客学习|大厂技术博客学习（2）——5G时代下淘宝直播高清低延时技术jie秘】码控需要解决两个经典问题：
一是帧级码控和块级码控根据目标码率来分配每个GOP、帧、编码块的码字数量
二是块内编码时以最合理的方式把这些码字分配到每个编码块中。

在帧级别码控中，传统方法统计所有已编码帧的长期复杂度, 根据长期复杂度及当前码率之间的比例计算出QP，这样一来，QP对帧复杂度越来越不敏感,导致编码质量下降或码率过剩。特别是在计算首帧qp时，以往算法采用了一个只和当前码率有关的经验值。我们基于cutree理论准确估计预分析长度中ipb帧的码率占比和预期编码大小，从而在编码前获得更准确的量化系数。

块级码控分配则受时域cutree和空域AQ影响。在时域上IBP帧的重要性是明显不同的，被后续帧参考的块，不仅影响自已本身的质量，还会影响到后续帧的质量，因此被参考更多的块需要进行高质量编码。cutree算法根据帧内预测代价和帧间预测代价计算信息的传递比例, 算出当前块对后续序列的影响程度，进而调整qp偏移。但考虑到在不同的噪声能量，运动强度，纹理边缘强度，以及编码参数下，不同参考块的调节为后续帧的节约比例是不一样的，所以s265通过参数训练的方法，获得多个因素对传递效率的影响，得到一个更准确的信息传递比递，从而更合理地在时域上分配码率。
另一方面，空域上各块之间的重要程度也是不一样的。人眼是视频的最终观察者，从人类视觉系统出发，不同的块在人眼中的视觉冗余不相同，比如人眼存在视觉掩蔽效果，它对显著纹理和强边缘附近的噪声不敏感, 将码率更多分配向人眼敏感的平坦区域，可以得到更好的主观质量。在编码器中，我们通过计算块的方差能量及边缘能量作为块的代价，研究不同块能量和人眼感知程度之间的关系，估计出块间码率配分对人眼注意力的影响，合理分配码率到更重要的纹理块，提高视频感知编码效率。

文章图片

※这一段我的理解就是根据经验，机器学习了一个分配码率的参数，文字很多怕删出歧义来，
我在另一篇文章里看到这个描述，我觉得比这里清晰多了

第1个，I帧的QP推导，X265使用了一个经验值，没有考虑到视频本身的特性，这样做很不合理，我们用预分析中低分辨率图像的复杂度和目标码率，经过多次迭代搜索得到准确的QP；
第2个，随着时间的推移，历史帧的复权重越来越高，新产生的帧权重越来越低，导致其不能很快的响应复杂度的变化，我们根据新产生的帧的参考强度计算出一个Qlamda，跟原来的Q做加权得到真正的Q，可以及时的反应新产生帧及其后续帧的复杂度；
第3个，原算法采用基于Viterb的P帧决策算法，每个帧都需要跟历史帧比较，复杂度很高，并在判决P帧时没有考虑QP的影响，准确率也不高。我们的算法只需要计算相邻帧的变化率，并引入QP来作为判决阈值，大幅降低了计算复杂度并提高了准确度。
块级码控分配则受时域cutree和空域AQ影响，s265在时域上越统计噪声能量，运动强度，纹理边缘强度，以及编码配置等参数与信息传递比例之间的关系; 在空域上，则从人眼视觉系统出发，计算不同块在感知模型中的价值，将更多码率分配给人眼更具注意力的区域。
论文：
An Exploration of Lookahead in Frame Bit Allocation and Slice Type Decision,
10.1109/TIP. 2018.2887200 , Zhenyu Liu, Member, IEEE, LiboWang, Xiaobo, Li, and Xiangyang Ji, Member, IEEE

不多评价，但思想就是之前提到的两个码控的经典问题，用了新的实现方式，正常操作吧

2.1.2 编码工具

在编码工具上，S265对传统的场景切换检测，帧类型决策，SAO，DEBLOCK，两遍编码，RDOQ等编码工具算法做了改进，并实现一批编码工具。

比如在参考帧模块, 有较多的工具可以提高参考效率。首先长期参考帧和广义B帧等帧类型可以提高预测质量，长期参考帧针对背景很少发生变化的直播场景，它有效减少信息经过多帧传递带来的损失，引用长期参考帧可将平均EV提高大概0.25dB。而传统P帧改为广义b帧，采用双向预测取代单向预测从而降低噪声，光照变化，采样误差等预测残差源。

大厂技术博客学习|大厂技术博客学习（2）——5G时代下淘宝直播高清低延时技术jie秘

文章图片

文章图片

在扩充了帧类型后，我们基于参考强度做IBP帧帧类型决策。然后在minigop内部，我们使用金字塔结构的参考关系, 得到比传统结构获得更短的参考距离。最后，在管理和选择参考帧时，我们考虑到静止块和运动块的区别，静止块倾向于参考质量高的帧，运动块倾向于参考时间近的帧，所以针对场景筛选出这两种类型的参考帧能得到更好的参考质量。
※关注场景的概念，场景的提出，一般而言实在基础业务稳定的情况下，针对个性化场景做优化，一般而言优化完还要能实现场景自动切换感知的功能，也就是自适应
再反过来看他的优化过程，从码控，到分帧，你可以理解为在做全链路优化

2.1.3 速度优化

HEVC编码器带来了编码效率的提升，但很多新的编码工具都存在计算复杂度过高的问题。因此，优化编码器速度，在高端机上能打开更多的编码工具，搜索更大的编码模式空间。进一步提升编码质量。在低端机上则能降低CPU发烫和编码卡顿的现象。

HEVC可以将图像块从64x64划分到4x4，同时块的类型模式激增，备选的编码模式数量是h264的数倍，块划分及模式决策因此成为一个重要的瓶颈。

文章图片

所以在RDO中，减少CU划分层级的搜索次数，筛选出一些必要的层级是减少计算量的重要手段。首先利用时间和空间相关性，可以从参考块获取到一些先验信息, 再结合本块的运动信息和纹理信息，分析预判出当前块CU层级的最大估计层级和最小估计层级。其次，在决策过程中的提前跳出策略也可以大幅降低计算量，我们根据图像纹理的平坦程度, 或者各种模式下的rdcost对比，提前跳出当前的模式遍历。而在一些图像非线性的场景，我们通过CNN深度学习模型辅助决策模式。

进入决策模块的内部，同样存在大量复杂的计算。帧内预测存在35种模式，我们可以通过贝叶斯理论，求出最简单的几种模式后，估计出最佳模式最可能出现的位置，从而为帧内模式筛选过程提升一倍速度并将损失控制在0.01db。另外，帧间预测的运动搜索是从参考帧寻找最佳匹配块的过程，它的分像素搜索需要做7抽头或者8抽头的插值滤波，计算量很大。我们所以可以利用整像素的信息建立二元二次误差平面方程，估算最佳分像素点的位置，避免了分像素的完整搜索过程。

在评价模式的优劣时通常采用rdcost作为模式的代价，它需要计算编码比特数和编码失真。这就需要将编码系数进行熵编码计算码流长度，同时还要将编码系数变换回时域求失真。为了降低rdcost的计算量，我们采用了失真和码率的线性估计算法，包括两个部分，其一是量化误差能量在频域计算，利用IDCT变换的能量不变性，计算量化余数的平方和估计失真，其二是建立编码系数特征信息和码流大小之间的线性关系，直接从系数特征信息估计出熵编码的大小。通过这个方法可以跳模式代价计算的熵编码过程以及，反变换，反量化，重建，SSE等过程。节约了大量的计算。

文章图片

在rdo之外，我们还改进了slicetype决策算法，动态拉格朗日因子调整算法，快速deblock和sao决策等。

在工程优化方面我们也添加了多项优化，首先是C函数优化，我们通过优化流程逻辑，拆分特殊路径，合并分支，查表，循环优化等方法给rdoq模块，系数解析，deblock等模块带来了接近一倍的提升；其次针对密集计算的函数我们simd化并优化汇编代码的执行速度。

s265经过快速算法与工程两个层次上的优化，我们为HEVC编码带来了明显的性能提升。从而在低端iphone上实现720P 30帧每秒的实时编码。
※能力范围以外，看不懂，但是思路上看，优化了生产端的编码过程，优化了传输过程中的编码过程，再到消费端的解码，这个还是不难理解

2.2 智能码控

智能码控是淘宝自研的码率控制算法，普通ABR或CBR码率控制为了追求目标码率，在低复杂度场景浪费了大量码率，根据人眼主观质量模型，当psnr高于一定阈值后再提高质量人眼无法察觉只会消耗过多码字。我们使用机器学习方法，根据17种历史编码信息和待编码帧的复杂度，预估出待编码帧在质量阈值以上的量化系数，并限定在ABR目标码率以下，确保每个帧都能以最合适的码率编码。

文章图片

文章图片

经过淘宝直播线上验证，可达到15%的省流，在钉钉直播中使用更是节省了52%的带宽并降低了62%的推流侧卡顿。
※自适应码控，我只是觉得文章写的有点乱，或许排版和逻辑更清晰一些回更好

2.3 场景编码

由于当前淘宝直播种类的丰富性，各种场景下的纹理，光照，背景，运动程度都是不一样的。户外主播经常走动，画面帧变化幅度频率高。美妆主播大多坐在室内，光照基本上比较偏亮。珠宝类主播主要是拍摄物品，画面多静止不动。面对形形色色的直播场景，单一的编码器配置并不能满足当前淘宝直播的需求，开启或关闭某些编码工具对视频编码效果影响不一致，如何针对内容选择最佳参数成为业界研究的方向。

文章图片

在此需求下，我们提出了基于不同场景的编码参数配置策略。首先，我们通过多个深度学习与机器学习模型对数万条各种内容的直播视频进行了数据训练分类，包含两个大的特征维度，分别是语义特征和信号特征。语义特征包含：主播分级，商品特征，环境特征，声音特征，时域空域RoI。信号特征包含：运动特征，纹理特征，噪声特征，亮度特征。通过对不同特征种类的视频集，我们单独使用大规模服务器集进行最佳编码参数搜索，自动化高效地搜索到适合当前视频编码的最佳编码参数组合，在提升画质的同时能尽可能地减少码率消耗。并最终根据编码参数集进行聚类分为多个参数配置项。

在主播需要推流的时候，首先进行标准的编码参数配置进行推流。收集一定的数据之后，我们将得到的视频语义特征和信号特征送入自适应决策引擎，通过里面的深度神经网络进行视频分类，决策出当前视频应该下发的编码参数配置，然后我们将新的参数配置重新送入编码器进行新的推流，以此优化使主播获得当前情况下最优质的视频编码。通过此方法，我们在淘宝直播里面获得了7-10%的BDrate收益。在淘拍场景下获得了40%的BDrate收益。
※我以为是预先设定好编码策略再开播，这里看的画是直播的过程中采样，再分类，再决策，再优化，这块不错，这样看的话，和外卖实时推荐那种也有点像，实时框架去做的，直播时间越长，用户越多，效果越好
2.5 画质增强
这部分单拿出来说都很多了，想看的去看原文，就是防抖，增强那套东西，绝对不新，我更愿意把它看作数字图像处理的内容

3.低延迟传输这部分就可看度很高了
3.1 低延迟播放器
常规播放器的延迟分析。目前基于TCP的直播传输技术主要有 HLS和RTMP/HTTP-FLV两个协议，其中HLS直播的延迟一般在10秒以上，HTTP-FLV直播的延迟一般在6到9秒，从推流、cdn分发到播放的整个直播链路看，延迟的大头来自播放端。在播放器中，几乎每个线程都有自己的缓冲区，这些缓冲区的作用是平滑整个播放链路的抖动，它们的大小决定了播放过程中的播放延迟和播放的流畅性。VideoBuffer和AudioBuffer用来存放待解码的音视频 packet，该缓冲区是为了平滑网络的抖动，推流、CDN传输和播放下载的抖动都会堆积到播放端，这是常规播放器延迟最大的一个产生点，为提升直播的整体流畅度，缓冲区延迟一般在5秒以上。

文章图片

基于TCP的媒体传输并不适用于低延迟直播场景，主要原因如下：

重传慢，TCP追求的是完全可靠性和顺序性，丢包后会持续重传直至该包被确认，否则后续包也不会被上层接收，且重传超时时间一般200ms，会造成接收侧帧抖动。
上层无法针对优化，TCP拥塞控制和 Qos 策略在操作系统内核层实现。
拥塞判断不准确，基于丢包的拥塞控制跟实际网络情况不符，丢包并不等于拥塞，也会造成发送链路 bufferbloat，链路RTT增大。

我们的低延迟传输SDK是基于WebRTC打造的，使用了WebRTC的几个核心模块，包括 RTP/RTCP、FEC、NACK、NetEQ、JitterBuffer、音视频同步、拥塞控制等。NetEQ和JitterBuffer分别是音频和视频的网络抖动缓存区，这是传输SDK延迟最大的一个产生点。RTP over UDP能够更好地对抗公网的丢包，结合自适应缓存和Qos优化，确保直播整体流畅度的条件下，我们的JitterBuffer的缓冲区延迟能够控制在700毫秒以下，直播观看延迟在1秒左右。

播放器对低延迟传输SDK的接入适配。我们对低延迟传输模块封装了FFmpeg的扩展demuxer，将支持低延时传输协议的demuxer注册到FFmpeg，播放器通过FFmpeg打开网络连接读取数据，这种接入方案基本不影响播放器原有逻辑，对播放器改动较小，主要改动点如下：

缓冲区大小控制。使用低延迟传输协议拉流时，网络的抖动缓冲区是底层传输模块的JitterBuffer，播放器层的JitterBuffer的缓存应设置为0秒，否则会引入多余的延迟。
卡顿统计修改。一般播放器根据缓冲区水位大小判断卡顿事件，当缓冲区为空或持续空一段时间，这会导播放画面卡顿，同时触发卡顿事件，播放器的JitterBuffer被低延迟传输SDK接管后，卡顿事件也应该由低延迟传输SDK触发。
音频解码流程。从NetEQ获取的音频已经是PCM数据了，播放器读取的音频数据可直接渲染，如果音频使用硬解，可能会出现解码兼容问题，现象是听不到声音，使用FFmpeg软解也是可以兼容的。

※没啥可说的，学
3.2 低延迟服务器

低延迟传输是一个综合性的问题，要从整体入手，不仅要从设计上考虑，还需要客户端，服务器，数据系统紧密配合。从传输协议设计上采用rtp/rtcp方案。基于udp半可靠传输，技术成熟，更加适合音视频场景。难点在于既要降卡顿，也要降延迟。我们使用的整体算法策略如下：

文章图片

拥塞控制

拥塞控制gcc&bbr算法针对直播场景深度优化，同时兼顾秒开和延迟。

分层丢帧

基于B帧的SVC算法和丢gop策略在网络拥塞时保证快速降低码率，解决拥塞。

重传控制

重传控制既要抑制重传风暴，也要保障快速重传。

平滑发送优化

平滑发送策略防止网络突发，平滑流量。同时针对秒开场景深度定制。重新设计发送机制和算法，发送性能大大提高。

秒开优化

服务器和端配合的多种秒开策略，保证极速开播。淘宝直播大盘平均秒开率94%以上。

信令优化

从信令设计上采用rtcp app私有协议，和音视频传输使用一个socket连接。建联协议更加精简，保障 1RTT快速给出媒体数据。
除此之外还进行了大量策略到算法上的改进和优化。上面整体策略，基于数据驱动，针对场景不断迭代优化。
※没啥可说的，学，标红的是对我自己思路有扩展的部分
3.3 端到端全链路分段统计

我们设计的端到端延迟分段统计系统，既能统计单次播放的总体延迟，也能统计每个阶段延迟。不依赖ntp时间，适合超大规模网络。通过分析不同平台推流端，服务器，播放器各个阶段的延迟情况，大盘展示出来，可以针对专项做优化。

文章图片

最后：关于BBR和GCC提供两篇博文
何时使用和不使用BBR - 菜鸟ccc - 博客园
实时视频传输中的BBR拥塞控制_LiveVideoStack-CSDN博客
回顾整篇，更多的是协议上的优化，从编码，到传输，到解码播放全链路的一些优化，当然还有很多优化措施都没有列举，我这里想表达的是，ML从12年起发展迅速，为参数优化提供了更多选择，但是这都是站在大厂的平台之上，精和广，管理和技术，人生只能选择一部分，让工作成为amuse你的那部分，或许才是最好的选择。
今天看到的其实和直播系统的实现而言，关系不大，那下次，我们看看怎么从头搭建一个全链路的直播系统
以上