音视频学习之闲看视频整理低延迟

2022年1月14日晚上闲听公开课：

​ 课程题目是元宇宙引入音视频相关知识。

​ 元宇宙相关话题不去理解，可以明确的是元宇宙有一个难点是音视频交互的低延迟。

​ 老师讲解的低延迟相关概念，对于我来说感觉挺有意义，忍不住做笔记整理。

1：了解延迟

在推流，拉流相关业务（如直播），从数据的采集发送到客户端接收到数据后播放，其实是有一定的播放延迟的。

如下图：使用rtmp(是基于tcp进行传输的)进行推流，然后使用不同方式对rtmp拉流播放，延迟误差。

从图中可以看出：

​ ===》使用ffplay进行播放时延迟是比较大的，默认是有缓存的。

​ ===》如果去掉缓存，可以对延迟有一定的优化。

​ ===》以及使用其他的一些方案，其实是可以把播放延迟进行降低的，那么降低延迟的方案有那些呢？

2：从直播的流程上进行分析：

下图从老师的课程中截取得图片，描述了直播从数据采集，处理，推流===》到流媒体服务器===》再到客户端进行拉流播放的流程。

如果要考虑直播延迟，其实是要根据这个流程从推流端，流媒体服务器，以及拉流端进行分析，同时要考虑网络抖动

3：从流程引入延迟分析

3.1：整体上分析延迟原因

3.1.1：延迟原因

音视频的直播一般流程是: 推流 ===》流媒体服务器 ===》拉流

影响音视频的原因一般有：

1：缓存 （有缓存就说明有数据的堆积，是延迟）

2：网络抖动（网络抖动会导致数据发送阻塞，或者一次性收到过多数据（需要做变速处理加快消费保证实时））

3.1.2：传输方案

udp相对于tcp，更适合音视频的低延迟传输。

rtmp底层使用的是tcp传输，tcp的可靠传输其实会丢失一定的实时性。

webrtc基于udp进行传输的，相比tcp，可以一定程度降低延迟。

除此之外，适用于音视频的另一套传输协议：quic(快速 UDP 互联网连接)

另外：现在市面上电商直播一般采用rtmp h264+aac 因为CDN支持比较高，虽然rtmp使用tcp传输，有一定的延迟。

3.2：推流端延迟分析

推流端一般包括：音频的采集，音频处理，音频编码 和视频的采集，视频的处理，视频编码，以及最终的推流动作

3.2.1：音频流的处理延迟

3.2.1.1：采样数导致一次采样会耗时

音频流的采集：采样延迟与设置的一次采样样本数有关。

===》假设采样率是44.1khz,设置一次采集1024个样本再处理，则采集等待耗时为1024*(1/44100),耗时23.2ms

===》如果采样率为其他，设置采样个数，其实采样上就已经有耗时。

2.2.1.2：音频处理会耗时

对采集到的音频做混音，降噪等处理，也是有延迟

2.2.1.3：音频编码也会有延迟

音频编码也有延迟 webrtc opus延迟比较低，但是aac有1~2帧的延迟

3.2.2：视频流的处理延迟

视频采集：一般25帧，采集到一帧就去处理喽
视频处理：（水印，美颜，滤镜）相关处理耗时一定要跟得上（软件/硬件） opengl比较快==》不要队列阻塞，处理耗时
视频编码： zero lantency（零延迟）, 不要用b帧

3.2.3：推流策略会导致的延迟

推流涉及推流策略，消费采集处理后的音频帧和视频帧。

采样本来就是实时采集的，推流应该是有数据就立马推流，不要缓存，越快越好。 ==》有延迟啊

3.3：流媒体服务器分析延迟

流媒体服务器涉及功能： 读数据，以及把数据推出去

3.3.1：流媒体服务器读数据策略

读数据，可能同一个数据，需要写给多个端去发送（如直播场景，多个人看）如何转发数据？

==》1：只有一个队列，读数据后，直接遍历fd进行写（如果其中一个fd卡顿，会阻塞）

==》2：每个写端有一个自己的队列，负责自己的数据写入。 （每个fd有自己的队列不影响其他模块）
设计队列时，如果有队列过多，满了（写延迟，消费过慢），可以设置覆盖。

3.3.2：（推流到服务器）读数据导致的延迟（多次读和一次读（内核态/用户态切换影响））

合并读取数据有延迟（有200ms的数据，每10ms读一次，是需要切换用户态和内核态，需要20次）

如何合并数据读取，200的数据读取一次，内核态/用户态切换1次 可以降低cpu。

3.3.3：服务器内部缓存队列会不会导致延迟

这里一般不会导致延迟，但是涉及队列消费过慢，如客户端卡顿，会队列中数据有过多。

客户端出现卡顿，客户端卡了5s，服务端对应的队列会缓存5s，恢复要让其发出去

网络恢复，如果一次拉取过多5s的数据,如果不做音频变速处理，客户端队列一直有延迟了。

3.3.4：（从服务器拉流）服务器写数据延迟

写数据（合并写处理）

==》有200ms要写，20ms写一次，与200ms写一次的问题。

==》效率高，更高吞吐量（带宽），但是有延迟，实时性差。

3.3.5：服务器配置(srs)，gop cache开启的影响（视频帧i,b,p帧）

视频帧有i帧，b帧，p帧的差异：gop就是两个i帧的差距

如果开启gop cache:服务器缓存一个gop，客户端从这个缓存的gop中i帧开始播放

===>最优场景： 客户端链接，gop中刚好获得i帧

===>最差场景： 客户端链接，gop中刚好从上一个i帧开始，客户端拉到上一帧的数据快速显示（如果不做变速播放，这里就会有延迟了，总是差一个帧）

===》开启gop cache的优点：可以快速显示画面。

===》开启gop cache的缺点：GOP可能直接至少延迟一个cache（网络抖动渲染等其他延迟）

如果不开Gop cache,也有最优和最差：（p帧和b帧是不现实画面的，黑屏）

===》最优：拉到i帧，直接解码显示

===》最差：刚好错过i帧，错过i帧，画面至少黑屏一个gop的时长，等到下一个i帧才能显示

webrtc有一个优化技术：

​ 客户端有请求连接时，服务器端先立马回复一个i帧的技术。

3.4：拉流端延迟分析

从上图可以看到拉流数据的流程：

拉取到服务器端的流后，音频流和视频流分别由专门的队列做缓存处理，去解码播放。

3.4.1：拉流端现象

1：缓存数据过多，要实时计算缓存队列的数据能播放的时长

===》帧间隔*帧数

===》最大的pts-最小的pts （pts 显示时间戳）

2：为什么打开有些播放器后，能听到声音的快速播放，如我在腾讯课堂听直播时就感受过

==》变速播放，为了快速消耗缓存中的数据 （直播场景，缓存其实就是延迟）

3.4.2：拉流端解决延迟(加速播放策略)

拉流端的延迟主要是：拉流后，缓存队列中数据有堆积，一直得不到消费（缓存导致了延迟）

==》尽快处理，加速消费就好了~

可以设置策略，使用加速播放来进行处理：

==》一些参数：缓存时间（触发变速），抖动值（回复正常参数），以及变速系数（控制变速速度）

起播：

========>检测缓存大于设置的缓存时间，开始播放，做变速处理，
========>如果缓存小于设置的缓存时间，则恢复正常播放

播放过程中：

==》抖动值：因为网络传输是有抖动的，抖动带来的缓存，如果按起播一样处理，就会陷入频繁的变速恢复中。

==》如果音频缓存大于 抖动值+设置的缓存时间 ==》触发变速播放

==》检测到小于设置的缓存时间，恢复正常播放。

注意:设置队列的缓存时间和设置抖动值，可以根据网络场景进行自己设置。

4:总结

推流 ==》服务器转发 ==》拉流

1：推流：注意采集延迟，音效处理，视频特效处理，编码延迟，有数据则直接推流，不要等待。

=========> 可以对队列帧数进行检测，根据帧数，判断网络，可以通过调整码率进行网络适配
2：服务器转发：

=========>合并读，数据队列，合并写
3：拉流

==========>数据队列，变速播放（sonic）,变速触发和恢复机制的设置

相关资料整理自免费视频：推荐免费订阅