音视频常见问题分析和解决：延时和抖动

延迟：是网络传输中的一个重要指标，测量了数据从一个端点到另外一个端点所需的时间。一般我们用毫秒作为其单位。通常我们也把延迟叫做延时，但是延时有时还会表示数据包发送端到接受端的往返时间。这个往返时间我们可以通过网络监控工具测量，测量数据包的发送时间点和接受到确认的时间点，两者之差就是延时。单向时间就是延迟。

抖动：由于数据包的大小，网络路由的路径选择等众多因素，我们无法保证数据包的延迟时间是一致的，数据包和数据包延迟的差异我们称为抖动。也就是说因为数据包的延时值忽大忽小的现象我们称为是抖动。

可以看出延迟会造成抖动，但是抖动并不完全等价于延迟，所以有时我们分析实际问题时还是要加以区分。

各个行业对延时的容忍度不一样，像K歌合唱就对低延时要求非常高。如果歌伴都唱完了上半句，你由于没有及时听到，下半句还没唱出来，对方是非常疑惑的。

但是我们也不能一味的追求低延时，低延时是好，但是会带来成本的上升。在实时传输领域有一个著名的三角理论。

成本我们可以理解为购买服务器需要的硬件成本、软件开发的人力成本和通讯带宽的租赁费用；延时就是上面理解的数据包端到端之间的时间差，质量可以理解为视频的清晰度和细节，音频的高保真以及数据的完备性。任何行业完成实时数据交互，都要受这三方面的因素的限制。如果过分追求低延时，要么我们要付出比较高的成本要么我们得下降我们的音视频质量。所以我们针对不同行业，选择一个用户能接受和不影响体验的延时即可。

本文福利，免费领取C++音视频学习资料包、技术视频，内容包括（音视频开发，面试题，FFmpeg ，webRTC ，rtmp ，hls ，rtsp ，ffplay ，编解码，推拉流，srs）↓↓↓↓↓↓见下面↓↓文章底部点击免费领取↓↓

关于视频的实时性归纳为三个等级：

伪实时：视频消费延迟超过 3 秒，单向观看实时，通用架构是 CDN + RTMP + HLS，现在基本上所有的直播都是这类技术；

准实时：视频消费延迟 1 ~ 3 秒，能进行双方互动但互动有障碍。有些直播网站通过 TCP/UDP + FLV 已经实现了这类技术，YY 直播属于这类技术；

真实时：视频消费延迟 < 1秒，平均 500 毫秒。这类技术是真正的实时技术，人和人交谈没有明显延迟感。QQ、微信、Skype 和 WebRTC 等都已经实现了这类技术。

对于严格的音频通话，当延时低于200ms时，就会影响到用户体验。达到400ms对方用户就容易感知出来，1s以上的延迟对于交互式实时直播就不能接受了。下面有一个表格基本列举了不同业务对于低延时的大致要求，当然即使是同一个业务，应用在不同的场景下对于低延时要求也经常不一样，这就导致我们解决问题的技术手段也是不一样的。在视频监控业务下这种差异更大，对于一些司法、监狱和博物馆，实时性要求很高，希望出现问题后立即能进行报警和进行查看，但是对于一些景区直播和学校社区实时性的要求就低很多。

延迟产生：

我们继续看下一个完整直播系统的示意图：

音视频从生产到消费的各个环节都需要花费时间来处理，这些时间之和就造成了视频观看方看的视频是视频产生方几秒之前产生的视频。我们对这些延时进行区分，会总结出以下四种类型的延时：

1. 处理延时：一般就是路由器要分析数据包头决定这个数据包要送到下一站花费的时间；

2. 排队延时：数据包从进入到路由器的发送队列到被发送之间经过的时间，路由排队算法和网络都会影响这部分延时。

3. 传输延时：将数据包传入到线路花费的时间，跟数据包的大小和带宽有关系。

4. 传播延时：是指数据包第一个bit位从发送端到接收端的时间，其和传输距离和传播速度有关系。

其实对于音视频系统，我们可以将上面讲述的三种延时归纳为下面几种：

设备端的延时：包括数据的采集、前处理、编码、解码、渲染等处理阶段花费的时间。也就是A1和A5花费的时间。

音频部分：

音频从采集后，会经过模数转换，将传统的模拟信号转换成数字信号就会产生延时，一般在10ms级别；采集后，进行编码，采用不同的音频编码器也会产生不同的延时，以Opus为例，延时也在2.5ms-60ms级别，可以参考上篇文章分析。发送前还需要进行3A算法（AEC、ANS、AGC）的处理，又需要十几ms.

视频部分：

从自然采光到成像，取决于CCD和CMOS的成像效率，不过一般也需要几十ms.对采集的RGB数据要进行YUV转换和编码，如果还有B帧会产生比较大的编码延时，紧接着播放端的渲染也是需要一定时间的。

无论音频还是视频，为了防止抖动我们一般会在播放端加上jitter buffer缓存，数据从进入到缓存到出缓存以及当发生丢包时，进行的一些传输算法处理也是需要一定的时间，大概会在几十毫秒到几百毫秒之间。

设备端和服务器的延时：也就是俗称的第一公里和最后一公里的延时，包括了A1到A2推流产生的延时和A5向A4拉流的延时。这里的延时跟设备端距离服务器的物理距离，服务器和设备端的网络运营商，设备的网速和带宽，设备端自己的负载都有密切关系。

服务器之间的延时：包含了音视频数据在网络上进行再次转码、切片、转封装和协议以及分发CDN等花费的时间，包含了A2到A4整个阶段花费的时间。这里要看设备的推流端和播放端是不是在同一个边缘节点，如果属于同一个边缘节点，那延时能小点。国内城市之间的传播延时也在几十毫秒，如果跨洲延时会达到百毫秒以上。

所以单就降低实时音视频系统延时一项内容，都不是靠只优化一个节点或者一个阶段就能达到你想要的预期效果，必须站在音视频整个系统来看待。

延迟测量：

测试方法1：

实际最简单的做法就是：我们让推流端也就是主播端比如手机或者IPC摄像头对着一个在线秒表，然后同时我们用手机或者桌面播放器播放该路视频，然后得到了在线秒表显示的时间，等稳定一段时间后我们将在实际线秒表的时间减去播放器显示的该时间，二者的差值就是当前的系统的延时。然后这种测试方法，每隔一段时间，测试多组，求其平均值就得到了当前负载下的音视频延时。

测试方法2：

我们也可以在编码端的视频帧前面加上SEI帧，SEI的全称是补充增强信息（Supplemental Enhancement Infomation）,提供了一种向视频码流中增加额外私有信息的方法。我们可以隔一段时间就在I帧前面的SPS PPS后面增加SEI帧，私有信息就是这时我们编码器的NTP标准时间，当该SEI帧信息到达播放器端，我们再计算下本地的NTP时间。这样本地的值减去SEI的NTP时间，就是当前系统的延时。前提条件，编码器和播放器进行过NTP校时，保证毫秒级别的时间信息要一致。

注：对于有些播放器如果增加SEI信息，可能会导致播放失败，所以解码前我们可以将使用过的SEI帧丢掉。

延迟优化：

经过以上的分析，我们就分析出延时产生的阶段和节点，这样优化延时就有了方法。延时会产生在：

1. 音视频数据的前处理；

2. 音视频数据的编解码；

3. 音视频数据的网络传输；

4. 为了防止抖动业务代码中的缓冲区，包括推流服务、转码服务、播放器的缓存等；

5. 音视频的渲染播放；

当然上面会产生延时的地方对于最终的延时影响权重是不一样的，其中数据的前处理、编解码、渲染对于延时影响比较小，而网络传输和业务代码的缓存对于延时影响非常大。所以优化也要结合你的业务有重点进行。

优化思路1：调整推流端和播放端的缓冲区大小，对于25fps的视频流，如果我们缓存25帧的数据，就会在播放时产生1s的延时。所以我们要动态调整我们的缓冲区，对于推流上行区我们如果带宽不够就会产生网络阻塞，这时发送端的数据就会积累，最终延时不断累加，导致延时变大。我们此时就需要有一套机制来能够预测带宽，降低发送码率，减低当前发送数据量，减少网络阻塞，等网络好的时候再继续增大数据发送量，增大码率。

上面说的这些算法有很多，其中WebRTC方案就采用了GCC算法，还有一些类似BBR的算法来实现上述想法。

对于播放端的缓存，当网络不好产生的延时比较大时，我们需要通过丢帧和加速播放方式快速消耗掉播放缓冲区的数据，从而消除累计的延时。

优化思路2：优化网络传输，如果实时性要求很高的场景，你如果选用基于TCP承载的网络传输协议，无论你怎么优化，也很难降低延时。因为TCP会进行三次握手，而且它会对每一次发送的数据进行确认，还要对丢包进行重传，所以这些限制很不适合降低延时。我们要优化传输协议，我们可以将基于TCP的RTMP、HLS协议切换到基于UDP的RTP、QUIC协议上，或者自己开发基于UDP的私有协议栈，这样我们就可以对一些TCP延时大的功能进行裁剪和修改，对于一些不关重要的数据进行丢弃，优先保障重要数据的传输。其中国内B站、虎牙直播，在线k12教育等都进行了类似的处理；

优化思路3：选择优质的CDN加速服务，保障传输的线路带宽和线路资源，一般都会提供测速选线、动态监测、智能路由等功能。

优化思路4：如果感觉自己的编解码，前期处理等花费时间比较多，我们就需要选择合适的音视频编解码器，进行算法调优降低延时，比如我们在播放端能支持硬解的优先选择硬解否则才选择软解。

上面所说的任何一种实践方法用一两篇文章都讲述不完，特别对于一些GCC、BBR等网络传输算法，依然是高校和大厂最前沿最热门的研究领域，需要用心学习才能落地到工程项目上，这里只是简单的提出，有兴趣的需要进一步搜索学习和实践。

本文福利，免费领取C++音视频学习资料包、技术视频，内容包括（音视频开发，面试题，FFmpeg ，webRTC ，rtmp ，hls ，rtsp ，ffplay ，编解码，推拉流，srs）↓↓↓↓↓↓见下面↓↓文章底部点击免费领取↓↓

音视频常见问题分析和解决：延时和抖动相关推荐

微信小程序 RTMP 音视频通话 ffmpeg_音视频常见问题分析和解决：HLS切片丢帧引起的视频卡顿问题排查...
问题背景: 前两天看读者留言让再写写音视频问题排查方面的思路,前面大概写几篇:<音视频播放疑难杂症分析和解决 :序篇>.<音视频常见问题分析和解决:延时和抖动>.<记一次 ...
ffmpeg 丢帧灰屏_音视频常见问题分析和解决：HLS切片丢帧引起的视频卡顿问题排查...
问题背景: 前两天看读者留言让再写写音视频问题排查方面的思路,前面大概写几篇:<音视频播放疑难杂症分析和解决 :序篇>.<音视频常见问题分析和解决:延时和抖动>.<记一次 ...
音视频常见问题分析和解决：HLS切片丢帧引起的视频卡顿问题排查
问题背景: 前两天看读者留言让再写写音视频问题排查方面的思路,前面大概写几篇:<音视频播放疑难杂症分析和解决 :序篇>.<音视频常见问题分析和解决:延时和抖动>.<记一 ...
详解音视频直播中的低延时
高泽华,声网 Agora 音频工匠,先后在中磊电子.士兰微电子.虹软科技主导音频项目.任职 YY 期间负责语音音频技术工作.在音乐.语音编解码方面有超过十年的研发经验. 音视频实时通讯的应用场景已经随 ...
详解音视频直播中的低延时 1
音视频实时通讯的应用场景已经随处可见,从"吃鸡"的语音对讲.直播连麦.直播答题组队开黑,再到银行视频开户等.对于开发者来讲,除了关注如何能快速实现不同应用场景重点额音视频通讯,另一 ...
音视频播放疑难杂症分析和解决思路
问题背景: 音视频相较于其他业务开发,门槛比较高的一个原因开发过程遇到问题比较多,而且每个问题背后都需要一定的理论基础和丰富的调试经验的才能分析出来.有些音视频开发小白,遇到一些诸如视频卡顿.声画不同 ...
驱动芯片在应用中的常见问题分析与解决
驱动芯片在应用中的常见问题分析与解决通信电源PSU在通讯设备中担任着很重要的角色,PSU问题将会导致整个通讯设备无法正常运作.常见的通信电源PSU拓扑有桥式.推挽以及正在兴起的非隔离IBB架构.所有 ...
WebRTC 音视频同步分析
文中提到的代码引用自 libwebrtc M96 版本 https://github.com/aggresss/libwebrtc/tree/M96 0x00 前言 WebRTC 音频和视频分别通过不 ...
Android 短视频 SDK 转场特效的音视频同步分析
在短视频的应用场景中,经常存在用户拍摄的两个或者多个视频生成一个视频的需求,为了达到两个视频平滑过渡,就需要在两个视频中间添加转场效果. 由于导入视频的帧率.码率等参数都不一致,如何保证在添加完转场效 ...

音视频常见问题分析和解决：延时和抖动

音视频常见问题分析和解决：延时和抖动相关推荐

最新文章

热门文章