流媒体源流常见问题与延迟分析处理

今天的内容分为播放器播放过程、直播源流常见问题、直播延迟的产生和处理WebRTC四部分快速直播。

播放器的播放过程基本上是推流的反向过程。推流端基于同一时钟源收集音频和视频，获得音频帧PCM以及视频帧YUV。由于相应的时空信息冗余，需要编码音视频，然后包装媒体格式。为适应网络传输，还要按照流媒体的相关标准协议进行再处理，最终获得输出流。播放是将推流过程反过来，通过流媒体协议分析输入流，然后解开包装，获得音频包(如常见的)AAC）以及视频包(如常见)H.264、H.265)然后通过解码获得音频帧PCM和视频帧YUV，最后，通过音视频的时钟同步，发送到相应的播放显示设备输出。

其中解码和音视频同步是影响播放的重要环节，这也很容易出现问题。音频和视频同步主要有三种策略，即音频时间优先、视频时间优先和外部时间优先。由于我们的耳朵对音频更敏感，音频和视频同步通常默认选择音频时间优先的策略。

随着浏览器的发展，现在H5Web播放也开始占据相当大的比例。H5的播放主要video标签以及MSE-API支持。通过多媒体内容SourceBuffer 输入后，浏览器通过解码视频和音频发送到音频和视频设备。目前浏览器还没有原来的支持H.265播放需要通过WASM支持，如将FFMPEG经过WASM然后外置解码视频。浏览器的主要播放过程类似于客户端的传统播放器，但从FLV/TS流到FMP4.转包装工艺。特别之处在于，音频播放并不完全依赖于时间戳，而是内容的连续处理。音频出现时PTS播放器需要进行额外的同步处理，否则随着时间的推移，可能会导致音频和视频不同步。.

本文福利， C 音视频学习资料包，技术视频，内容包括(音视频开发，面试题，FFmpeg ，webRTC ，rtmp ，hls ，rtsp ，ffplay ，srs）↓↓↓↓↓↓见下面↓↓文章底部↓↓

播放端常见的问题主要集中在播放失败，播放没声音，音画不同步或者画面卡住不动，出现延迟很高等等。造成这些问题的常见原因有几类，这里结合案例展开讲一下。

第一类是时间戳和流畅度不理想

在左侧，客户反馈流播放时，音画明显不同步。使用ffplay播放流地址或通过源流wget/curl另存本地文件后，使用ffprobe分析其音视频时间戳。从图中可以看出，这个音视频的时间戳差距很大。当音视频时间戳差距过大时，播放器可能会放弃音视频同步。这个例子是源时间戳DTS/PTS不理想导致的不同步。

右边的案例是直播频繁卡顿，但录制的文件播放流畅，没有频繁卡顿，但最终获得的文件播放时间不够。通过分析源流的上行流畅曲线，发现实际收到的音视频数据只有3秒(如5秒内).5秒钟内，媒体内容不足，导致播放器数据缓冲不足，导致直播频繁停滞，最终录制文件时间不足。其原因通常与网络带宽有限时数据积压有关。当没有合适的丢帧策略时，客户端的网络带宽是有限的，这种现象很容易发生。

第二类，关键帧的间隔设置不合理

例如，在左侧，一些观众反馈流的播放延迟很高，达到8-9秒。在播放客户的流程地址时，发现最初发布的音频和视频内容较多，然后分析客户的来源，发现GOP(关键帧间隔)约10秒。在这种情况下，视频GOP过大引发CDN缓存过长，播放器缓存过多，延迟过大。

在右边的情况下，客户的原始流地址无法播放，但转码流可以正常播放。分析了客户的播放文件，发现没有关键帧。原因是设置了一些编码器，GOP不合理，整个过程只有一个关键帧，导致直播无法正常观看。然而，重新编码后，关键帧间隔正常，可以播放。

第三类是缺乏或不匹配音视频解码的关键信息

当关键信息缺失或视频解码不匹配时，现象更为明显，主要表现为无法播放或花屏。但当音频解码器信息缺失或不匹配时，现象相对隐蔽。例如，在左边的情况下，有些播放器没有声音，但是ffplay播放正常，有声音。使用ffplay 播放客户源流时，发现没有显示音频profile。一般情况下，播放源流时会显示音频profile为LC或者HEAAC、HEAACV使用了音频编码SBR和PS)，在进一步分析客户源流日志时，发现源流缺乏音频解码信息。因此，造成这种现象的原因是客户在推送时没有推送音频解码头，导致一些播放器，如ffplay可以正常播放，有些播放器不能。

右侧的例子与解码关键信息不匹配有关。客户反馈ffplay播放正常，VLC一开始很正常，但后来的延迟越来越高。经过分析，发现客户的源流音频内容实际上是按照44进行的.1Khz编码。但当其解码信息传输到服务器时，指示为48Khz。音视频解码信息不匹配，导致播放异常。

第四类音视频内容存在设备兼容性问题

在左边的案例中，内容在其他平台上，如PC、Web、安卓播放正常，但在iOS上的HLS无法播放流量。使用ffplay 播放客户源流时，发现客户源流使用场编码。现场编码主要用于传统的电视直播场景，苹果手机iOS系统不支持现场编码播放，导致HLS 不能正常观看。其他在iOS常见的不兼容和自定义SEI不符合标准，profile/level不兼容等。

右边的案例与音频内容有关。源流在ffplay 、vlc播放正常，但在一些移动终端上没有声音。分析了客户源流的时间戳、帧率和各种解码信息。但是通过音频内容AdobeCC该工具发现音频内容的相位相反。当收集代码的设备相位调试异常时，会导致音频内容相位相反。有些设备在合并声道内容后输出，声音可能很弱或没有声音。独立输出声道的设备，如耳机，会表现正常。

综上所述，要尽量避免源流的常见问题：

1. 尽量保持源流的时间戳、流畅度正常；

2. 设置合理的源流GOP，既不能太大也不能太小。GOP在1-4秒之间；

3. 确保音视频的解码信息发送到服务端；

4. 避免使用场编码、非标准等特殊编码SEI等等；

常用的分析工具有以下几种：

1. ffmpeg、ffplay、ffprobe套装主要用于分析解码、时间戳等相关内容；

2. 使用elecard analyzer辅助分析264内容类似SEI的相关内容；

3. 使用AdobeCC分析音频内容，判断是否存在相位相反的问题，或者音频基本处于静音状态，没有能量。

直播延迟的产生与从推流到云再到观众的整个环境有关。推流端收集预处理，然后编码，推到云接入。然后云通过媒体处理CDN分发和传输。最后，通过解码和后处理在观众端播放。延迟主要来自链路中的数据积累、推流、传输和下行播放，可能会产生数据积累或延迟。

在实践中，影响延迟的主要因素如下：

1. 选择上行编码参数；

2. 音视频时间传输是否交织；

4. 链路传输、线路相关的延迟，以及TCP可靠协议带来的延迟；

5. GOP的大小；

6. 下行播放抗抖动缓冲的能力。

常见的协议，比如说RTMP、HTTP-FLV基本上可以做到延迟2-3秒之内。HLS的延迟大概在6-20秒左右，这个值主要依赖于GOP的大小，切片的大小以及切片的数目

直播延迟的常见测量方式有两种。第一种是端到端的播放对比，比如说在推流端，推流采集网页时间，然后在播放端通过对比直接可以得到延迟（这里是一个WebRTC播放的例子，可以看到延迟在500毫秒以内）。这种端到端的播放对比，需要有一个良好的低延迟播放器。如果手头暂时没有的话，ffplay配合-fflags nobuffer可以简单用下。第二种是在推流端中插入自定义的SEI内容，通过携带本地时间戳进行粗略估算。比如说发送端，将本地时间戳以json 的形式放进SEI里，播放端解析到这个SEI后，获取本地时间与json中的时间戳进行比较，得到端到端的链路延迟。这种方法要求两端之间的本地机器时钟不能差异太大。

实践中影响延迟的这几个主要因素中常见的首先是推流端上行编码参数的选择，如果是采用软编码，比如X264，一些参数的设置会影响到它的延迟，比如说rclookahead 与frame threads的数目，还有是否使用B帧以及B帧的数目。随着编码预设preset的增加，从veryfast、faster、fast 到medium ，lookahead的数目从10-40帧不等，以常见的推流编码帧数（FPS15）为例，会导致的延迟额外增加从660ms对应增加至2300ms。这个就是为了提高图像质量、编码速度导致引入的额外延迟。

本文福利， C++音视频学习资料包、技术视频，内容包括（音视频开发，面试题，FFmpeg ，webRTC ，rtmp ，hls ，rtsp ，ffplay ，srs）↓↓↓↓↓↓见下面↓↓文章底部↓↓

第二个影响延迟的因素是音视频交织同步，即使用ffmpeg时，音视频交织同步等待会导致额外的延迟。比如说视频的时间戳t1、t2、t3与音频的时间戳，t0、t1、t2并不完全一致时，存在缓冲区的重排，在等待过程中，会产生额外的延迟。

第三个是网络传输本身存在时延RTT。例如测试ping www.qcloud.com的结果，平均时延大概在30-40毫秒之间。在海外，部分地区网络设施较差，这个时延可能会到100-200毫秒。另外现在传统的推流直播主要基于TCP的可靠传输协议，在ACK弱网丢失的时候，容易造成延迟的扩大。例如客户端发送了一段数据之后，等待服务器和ACK，如果超时200毫秒还没收到，那么下一次客户端会进行重试。但是如果下一次的ACK再次丢失，超时时间有可能会扩大到400毫秒。如此累加，整体的延时会变得不可控。

影响延迟的第四个因素，是GOP的大小。播放器在接入CDN时，CDN通常会从最近的GOP下发数据。GOP的设置会影响播放器接入初始发送的数据量。比如播放端连接到CDN节点时，CDN的缓存目前有8秒，那么CDN将这8秒发送给播放端之后，就会产生初始的8秒延迟。

最后一个因素是网络抖动，导致缓冲累积。当网络抖动时，容易出现数据的波峰波谷，播放器会出现数据累积。假设在单位时间5秒内，由于网络卡顿，只收到了2秒的音视频内容。那么播放器有可能在播完这2秒后，就会卡住，等收到后面的8秒内容之后，再按照正常的节奏去播放，也就产生了额外的3秒延迟。如果这个延迟得不到有效的处理，那么随着时间的累积，抖动次数的变多，延迟也会越来越长。

这里为大家介绍一些降低延迟的可选方法：在常用的OBS的推流软件中，可以将编码tune设置为zerolantency，此时它的rclookahead 基本上为0，也没有frame threads，也不使用B帧，延迟比较低。还可以将GOP设置在合理范围，比如两秒，CDN节点下发的缓冲较少，有利于播放器降低延迟。此外还可以为播放器主动增加追帧的能力，主动去丢帧或者是采用soundtouch等快速播放，来降低延迟。如果是H5的Web播放器，适当控制playbackrate的属性，也可以有类似的效果。同时推荐使用一些成熟的播放器，比如说腾讯云视立方的SDK。针对推流接入如果有条件可以采用HTTPDNS获取最佳的调度节点，避免localDNS干扰。最后还可以考虑采用其他的非TCP上行协议，例如SRT等推流。具体的OBS及视立方设置，可以参考右侧的截图。

传统的直播，延迟经过一定优化能够低至2-3秒就很不错了。如果想进一步优化延迟，要做到毫秒级别，完全放弃缓冲区，或是将缓冲区控制的特别小，很有可能会导致卡顿率的大幅上升。

而快直播基于WebRTC低延迟技术打造，能够在保证卡顿的同时将延迟降低至毫秒级，满足了对延迟性能要求更高的场景需求，比如在线教育、体育赛事直播、在线答题等。同时它兼容了标准直播，包括推流、转码、录制、截图、鉴黄、播放等全功能，支持客户从现有的标准直播业务平滑迁移。客户既可以选用WebRTC接入，也可以使用传统的RTMP方式，基本上不修改用户的使用习惯。在播放端，快直播使用WebRTC来获得毫秒级的低延迟，同时抗卡顿的效果。

WebRTC快直播和普通直播相比到底做了哪些内容，或者是具有什么样的优势，使得它在延迟降低的同时，卡顿率又不上升呢？普通直播的主要问题首先是基于TCP的可靠数据传输，存在ACK延迟确认、弱网数据积压等。另外普通直播的播放-传输-网络三部分相互割裂，对于缓存的调整没有联动，因此过于降低缓存会造成卡顿率上升。

而WebRTC快直播基于UDP+NACK，可以实现快速重传。当RTT较长时，快直播可以提高FEC的冗余，使得不需要借助重传，直接通过冗余的数据包就可以进行恢复。另外通过带宽估计算法动态调整jitterbuffer，使得缓冲更适应当前网络的状态。同时快直播通过pacer机制降低对网络带宽的压力，比如在发送I帧时，快直播能够对I帧进行分片传输，避免因I帧数据内容较大引起网络抖动丢包，使得网络发送的更为平滑。最后，快直播会对传送媒体的优先级进行区别处理，例如音频优先、视频I帧、P帧、B帧分级丢帧，在网络带宽有限时优先丢弃一些没有参考的B帧，通过降低数据发送量，来避免网络带宽的压力。

上图是快直播与标准直播在推流端参数相同的情况下（1280x720，15FPS，1800Kbps），主播端无损网络，客户端设置不同弱网的对比结果。在丢包30%的情况下，FLV帧率只有10帧，而快直播还有14帧。丢包50%的情况下，FLV只有2帧，快直播仍能保持13帧水平。整体对比来看，快直播在网络抗性以及延迟等方面都具有相当大的优势。

原文链接：流媒体源流常见问题与延迟分析处理 - 资料 - 我爱音视频网 - 构建全国最权威的音视频技术交流分享论坛

本文福利， C++音视频学习资料包、技术视频，内容包括（音视频开发，面试题，FFmpeg ，webRTC ，rtmp ，hls ，rtsp ，ffplay ，srs）↓↓↓↓↓↓见下面↓↓文章底部↓↓