新知第一期 02 延迟问题分析原创

大家好。呃，我是来自腾讯云音视频的流媒体工程师付秋平。今天我为大家带来的分享是流媒体源流常见问题与延迟分析处理。今天的内容主要分为下几个部分，第部简要介绍一下播的播。第二部分是啊，我们介绍一下直播常见问题，结合一些常见的案例啊，进行一些分享。啊，第三部是直播延迟的产生和处理。由这个延迟的产生与处理，我们再简要介绍一下第四部分外I快直播。第一部分播放器播放流程。播放器的播放流程啊。基本上是推流的一个逆向的过程啊，我们的推流呢，基于同一个时钟源进行一个音频啊和视频的采集，得到一个音频PCM。

啊，音频帧，然后视频的是YV视频帧，然后由于这个存在啊相应的。时空信息冗余，我们要需要进行一个编码，然后得到一个封装。啊，为了这个适应这一个网络传输，我们要按照流媒体的相关的标准协议，然后进行一个啊再次处理啊，得到一个输出流。那么这个播放呢，就是这个推流的一个反过来的一个过程，它由这个输入流经过一个解这个流媒体的一个协议，然后呢，经过一个解封装啊得到一个音频，比如说我们常见的A啊得到一个视频，比如说们常见的646。然后再经过一个码得频P，最后经过一个音视频的一个。

然后最后送到这个，呃，音视频设备，比如说外放。耳机啊。视频帧进行一个相应的显示。其中解码音视频同步呢，是主要影响播放的重要环节，相应出问题也是比较多，在这两个环节啊。在音视频同步这个策略方面呢，啊，主要有三种策略，一个是音频时间优先啊，视频时间优先，还有一个是外部优先。啊，其中由于这个啊，我们的耳朵对这个音频啊，它更为敏感，所以通常音视频同步啊，默认都是音频时间优先的一个策略。随着这个浏览器的发展啊，现在H5WEB的播放呢，也逐渐占有一个相当大的组成部分。H5的播放呢？主要是有标签以及这个MAPI的一个相关支持啊，我们将这个多媒体的内容通过这个S。

视频以及音频的解码啊，最后送到这个音频设备和视频设备。经过这个W的一个编译，进行一个外置的支。浏览器上的主要播放过程呢，与客户端的这个传统播放器基本上是一个类似的过程，只不过它增加了从tag。批次的一个转封装过程。其中比较特殊的一点是，它的音频播放并不是完全依靠这个时间戳，而是这个内容的连续处理啊。当出现这个音频的跳变。

啊，或者是因为传输的原因导致了这个音频的丢帧的时候啊，需要进行一个额外的同步处理，否则呢，随着这个时间的推移，有可能导致因视频的不同步。第二部分是直播源流常见的一些问题，下面我们就一些直播流常见的案例进行一些分享。播放单常见的一些问题啊，主要是集中在如下的几类，比如说啊，为什么我的牛播放不了？为什么它播放没声音？啊，为什么这个不同步或者画面不动啊，为什么这个延迟很高等等。啊，常见的原因啊有啊第一类，比如说与我们这个时间戳相关啊，时间戳与这个流畅度不理想。啊，比如说啊第一个例子。

我们的客户反馈啊，这一个流它播起来之后啊，有有这个明显的硬化不同步。我们使用这个去这个址或者这个呢，W或者另个文件之后呢，使用这个间这个时间。啊总结一下，就是这个这个音视频时间差距过大的时候。播放器会有可能放弃这个音视频同步啊到它的，呃，直接原因就是原的这个时间，它的DTSPTS等，这个是不理想的。啊，第二个案例是啊，直播的时候播放呢频繁卡顿，但是录制文件录制下来之后呢，播放的时候呢，还是比较流畅的，没有那个卡顿的现象，只是他最后得到的这个时长是不够的。

我们通过分析这一个的上行呢，它一个长度的一个曲线啊，发现它在上行呢，啊位时间，比如说五啊增。过来这个音视频的数据呢，实际上只有3.5秒的音视频数据。他这个媒体内容一直不足，会导致这个播放器啊，没有足够的数据缓冲。啊，引起直播会频繁卡顿啊，最后录制文件的这个时长是不足的。其原因呢，通常与网络在受限的情况下呢，数据会产生积压啊，客户端的网络受限，然后没有合适的这个纠正策略的时候。会容易导致这个现象。啊，常见原因的第二个呢，就是这个关键帧的它的一个间隔设置设置不太合理。比如说啊，这里有一个现象是部分观众啊，他反馈这个牛的播放延迟很高，达到了这个八到九秒。我们去拉链播放这一个客户的留地址的时候呢，发现他初始下的音视频的内容是比较多的，分析客户的原流呢，发现go关键帧的间隔有十秒左右的现象。

在个股过大的时候呢。有可能引发这个CDN的缓存。播放器的缓存过多的时候呢，容易延迟过大。第四个案例是啊。客户的原始流地址，它的播放是失败的，但是转码流可以正常播放。我们去分析这个。客户的播放文件，发现它是没有关键帧的。这个原因就是啊，部分编码器的设置的时候啊，不太合理。出现了全程只有一个关键帧的现象啊。造成直播无法正常观看，因为播放要从关键帧开始，但是转码流呢，经过了重新编码之后呢，它的关键帧。就可以了。所以这是啊，两个关键帧设置。

有关的一个案例。第三个原因就是音视频解码的关键信息缺失或者是不匹配。啊，当视频解码关键信息缺失或者不匹配的时候，现象是比较明显的，主要表现为不能播放或者是花屏。当音频这个解码器信息缺失或者不匹配的时候呢，它的现象是比较隐蔽的。啊，比如现在啊，这里有一个例五，就是播放的播放器没有声音，但是iPhone播放正常是有声音的。客户反馈录制这个HS文件失败。啊，我们使用这个Apple play播放客放客户的源流的时候，发现它没有显示出这个音频的profile啊，正常，如果。这个播放正常的时候会显示出比如说LC。者是中含有这个S显示H字样。

啊，分析这个客户的日志的时候呢，发现缺少音频的解码信息啊。这个原因就是客户推送的时候，他没有推送这个音频的码头啊那啊。会导致这个播放器啊，有的人正常播放啊，有的是不行的。啊，第六个例子呢，就是啊。与客户的这个解码关键信息不匹配相关的。它的主要现象就是正常啊VC刚开始正常，但是后面这个延迟是越来越高了。客户的原有的音频内容实际是时间间隔是按照44.1K赫兹啊进行了一个编码。但是他的解码信息传递给啊服务端的时候呢，只是为48K赫兹。当客户的推流的这个音视频解码信息不匹配的时候啊，也容易导致这个播放产生啊各种异常。

第四个常见的问题就是音视频的内容。比较特殊，存在一定的设备兼容性问题。啊，比如说有一个现象是其他的平台，比如说安卓。各个平台播放都是很正常，但是只有在iOS的上，这个HS播放不了。我们使用这个f play播放客户的流时候，发现这个提示客户的流使用的编码。场编码主要用于传统的电视直播场景。消费类电子设备啊，苹果手机iOS系统啊。一般是支持这个码播放，它会造成这个H无法正常观看。还有比如说自定义的SSEI啊，符合这个标准的。苹果系统本身对这个啊。留的内容的要求是比较严格的。

啊，第四个案例与音频的内容有关啊。比如说现在这个现象是Apple play呢，VC啊等播放都非常正常，但是呢，部分的移动端是没有声音的啊，我们去分析客户的原有的时间戳啊帧率。各种解码信息都是正常的。啊，但是把这个音频的内容啊，通过到BCC这个工具去分析的时候发现的内容啊，相位是相反的。当采集编码的设备它的相位调试异常的时候，会造成音频的内容相相反。当部分设备合并这个声道内容输出后，有可能会造成声音很弱。或者没有声音升到独立输出的设备，比如说耳机啊。他就会表现正常。这主要是与项目相关有关的一个。总结来说就是啊，原常见的一些问题呢，尽量避免以下的一些问题。

一是尽量保持原流的时间戳啊流程度正常。第二是设置合理的源流构。既不能过大，也不能过小，和你的客户在一到四秒之间啊，第三是确保音视频的解码信息啊。发送到。服务端。第四呢，尽量避免使用一些特殊的。啊，编码啊编码，比如说非标准的啊等等。啊，当然也可以寻求这个云上专家的帮助。我们常用的一些分析工具呢，主要有如下几类，第一部分呢，是iPhone iPhone iPhone pro的一个套装，主要用来分析解码。时间戳等相关的一些内容。第二部分呢，就是也可以使用这个any。它可以辅助分析这个264牛里面的内容，比如说这一个。啊，第三部分呢，啊，也可以使用刀啊。

进行分析这个音频的内容啊，判断它是否有相位，相反，或者是这个音频没有能量啊，基本上处于静音状态等等。下面是第三部。这里简要分析一下直播延迟的一个产生与处理，也是上面常见问题中的其中一类很典型的问题。直播延迟产生的一个背景呢啊，主要是与从推流到云端到观众的整个环境有关。我们的推流端经过一个采集，然后啊预处理，比如说这个瘦脸啊，大眼大眼美颜等等，然后再经过一个编码，然。啊，推到云端进行一个接入，然后云端经过一个媒体的处理，比如说水印转码，最后经过一个CDN的分发与传输。最后在关注经过一个解码后处理，比如说挂件的特效。等等最后呢，播放出来。

啊，延迟主要是由数据堆积产生。推流传输下行播放了。都有可能会产生这个数据堆积。也就都有可能产生延迟。实践中影响这个延迟的主要因素如下几个方面啊，一部分是上行编码参数的这个选择。第二是in。是啊，时间传输是否选择了交，第三是链路传输线相关的一个延迟，这个TCP可靠协议啊带来的延迟。第四个是这个大小。第五个是下行播放的一个对。抗抖动缓冲的一个处理能力。常见的协议延迟了，比如说。两到三秒钟之内。然后HS的延迟呢，大概在六到20秒左右，它主要依赖于这个构谱的大小，切片的大小以及这个切片的数目有关。

直播延迟的常见测量方式啊，第一种是端到端的一个播放对比。比如说在推流端啊。推举一个网页的一个时间啊。然后在播放端啊，这里是一个IDC的啊，可以看到这个延迟大概在500毫以内啊，端到端的一个播放对比。他需要有一个良好的低延迟播放器啊，如果现在手头没有的话。X buffer也是一个勉强可用的选择。啊，第二个呢，就是在推流端中呢，插入自定义的C的内容啊，通过携带这个本地时间戳。经过进行一个粗略的估算啊，比如说发送端啊。将本地间以一个的形式放进这个里面。播放端解析到这个Sai之后。或者获取本地的一个时间。

然后与这个。中的这个时间进行一个比较啊，得到一个的电路延迟啊。这个要求呢？两端之间这个机。影响延迟的主要因素之一呢啊。下面详细的分别介绍一下啊，第一就是推流端，如果是采用的软编的时候，X264的这样一个参数会影响到它的延迟，比如说我们常见的R与这一个集编码的目，还有是否以及逼的这个。啊，比如说啊，随着这个增加的这个默认值。啊，也从fast fast。Plus和medium啊，分别啊由十变到20 30以及40，如果以啊常见的这个料编码增数，比如说15FBS为例，那么呢，会导致的延迟额外增加从600毫秒啊。

到一啊1300毫秒啊，最终会增加到比如说2.3秒之多。这个是由于啊，提高这个图像的质量以及编码速度呢，会导致一个额外的延迟。啊，第二个影响延迟的因素呢，就是说。啊，如果使用iPhone，它这个音视频的交织同步等待的时候也会导致额外的延迟，比如说视频的时间错。T1 T2T3与这个音频的识别错。今年T1T2啊，它并不是完全一致的时候啊。存在一个缓冲区的一个重台啊。在这个缓冲区的等待过程中啊，也会产生一个额外的延迟。啊，影响延迟的其他因素，第一是网络传输的本身呢，它存在一个实验的RT。比如说拼这个lo的一个结果啊，我们可以看到它的。平均时间啊，大概在30~40之间啊。

短的是几毫秒啊，但是在海外的时候呢，比如说它也可以啊，这个100~200毫秒之间，那么这个延迟也是不容忽视的。啊，第三个呢，就是啊，现在传统的推流直播主要基于这个TCP的可靠传输协议。啊，当他在这个艾可入网丢失的时候呢，容易造成这个岩石的扩大。啊，比如说客户端发送了一段数据之后。等待这个服务器和一个APP。那么这个超时，比如说200毫秒还没收到，那么下一轮客户端会进行一个重试啊，但是这个啊，如果下一次的艾克再次丢失，那么这次的超时时间有可能会扩大到。那么整体这个累计的延时啊，会变得比较大，不可控。啊，影响延迟的第三个因素就是前面提到的啊，它的个股设置大小影响这一个延迟。播放器在接入CDN的时候，CDN通常会从啊，最近或者年轻的构去下这个数据。

个谱的设置呢，会影响播放器接入初始发送的一个数据量。比如播放端连接到CDN节点的时候。比如说CDN的缓存目前有八秒。那么CDN把这八秒发送给播放之后。就会产生这个初始，比如八秒的一个因子。啊，还有一个就是网络抖动呢，会导致这个缓冲的累积。当网络抖动呢，容易出现这个数据的波峰，波谷。播放器会出现这个数据累积越来越差。比如说在前单位时间五秒内啊，因为这个网络卡顿的原因啊，只来了两秒的内容，那么啊播放器有可能播完这两秒之后啊，它就会卡顿卡住这里啊等后面的八秒内容来了之后呢，他有按照正常的节奏去播者啊五秒的内容，那么就会产生这个额外的三秒延迟。啊，如果这个。

延迟得不到有效的处理的话，那么随着这个时间的累积，抖动次数的。那他的这个延迟也会越来越长。啊，降低延迟的一些可选方法啊。下面比如说啊，我们常用的这个OBS的推流软件里面呢，可以考虑设置这个。第二个是呢，将这个构设置在合理范围，比如说秒CD节点下缓较少。有利于播放器降低延迟。第三个呢，就是播放器主动增加最帧的能力啊，主动去丢帧，或者是采用一些啊touch这一些库去快速播放来降低一些延迟。啊，如果是H5的web播放器呢？啊，适当控制这个play的属性也可以有类似的效果。

使用器。这里也可以考虑使用立方的SDK。第个就是推的播放接入，如果有条件可以采用HPD获调度。避免local DNS的干扰。造成这个选举的节点并不是最优。然后导致。显示长，网络不佳。啊，第四个呢，是可以考虑采其他的商品协议非TP如S。跟这个推流。式来控制这个缓冲区域，以及这个最深的速度啊。啊，当然也可以配置CDN下这个缓存的大小。优化这个延迟的选择。

第四部分呢，我们简要介绍一下这个外部RTC的直播。啊，传统的直播延迟呢。经过一定的优化能够做到啊，比如说两秒到三秒啊。这种酒。算是不错了，如果想进一步的这个优化，延迟要做到这个毫秒的级别以内啊。完全放弃这个缓冲区，或者把这个缓冲区控制别。那么呢，很有可能会导致这个卡顿的上升。啊，但是快直播呢啊，是专门针对这个基于外部RTC的一个低延迟的技术，还是满足这样一些对延迟性能要求更高的一些特定场景需求。啊，比如说啊，适合于在线教育啊，体育赛事直播在线答题的。啊，它兼容了标准直播，包括推牛、转码、录制、截图、鉴黄、播放等全功能。支持客户呢，从现有的标准直播业务平滑迁移。

客户可选的推流方式呢，既可以选用这个外部IDC接入，也可以使用传统的。TP方式啊，基本上不修改用户的使用习惯。然后在播放端呢，使用这个外包IDC来获得一个良好的低延迟以及抗卡顿的一个效果。那么。普通直播和web r TC的这个快直播相比啊。这个。快直播。到底是。做做了哪些内容，或者是具有什么样的优势啊，使得他在这个延迟降低的时候，卡顿率又不上升了啊。主要是啊，普通直播呢，它是基于TCP的一个可靠的数据传输存在。艾可延迟确认，然后入网数据积压等等。另外就是它的播放传输网络啊。这三部分是一个割裂的行为，对于缓存的这个调整呢，基本上没有联动。所以会造成它过于降低这个缓存的话，会造成卡顿上升。

R。它第一是基于这个udp协议啊，或加实现在一个快速重传。第二是当这个比如说RTT啊，比较长的时候啊，我们可以考虑适当加了这个fec的这个恢复机制啊。使得这一个。数据包不需要经过重传啊，直接通过冗余的数据包啊，就可以进行恢复。啊，第三个呢，就是他。啊，一个良好的带宽预测算法，动态调整这个buffer，使得这个buffer更适应当前网络的一个状态。还有就是呢。比如说在发送这个帧的时候，会产生一个大的网络抖动，因为I帧相对比较大的啊。它通过一些配色机制，对这个癌症进行一些分配啊，传输啊，降低了这个网络带宽的一个压力啊，使得这个网络发送的更为平缓。

第五个呢，就是对这个传输的媒体的优先级啊，进行一个区别处理。比如说音频有些啊，视频癌症。逼真逼增啊，在这个网络带宽啊有限的时候，可以考虑有些比如说丢弃。没有参考的一些逼。通过来降低这个。数据发送量，避免这个网络的压力。那么我们可以看一下这个快直播对比标准直播的一些结果。同样在推流端参数180P180乘720P的情况下，15FPS啊，1.8兆的。状态下。主播单位，无线网络。客户端设置不同的这个落网的一个对比结果啊。比如说在，呃。丢包30%的时候，FV基本上帧率只有十帧，那快速包还有14帧，那丢包50%的时候呢，FV基本上只有两帧了。快速还能保持一个13帧这样一个水平。

整体整体对比来看呢，啊快直播在网络抗性以及延迟等方面都具有相当的优势。所以呢啊，也推荐大家啊。有兴趣的可以考虑啊。去尝试一下会直播。啊，我今天的分享就到这里结束了。谢谢大家。