一、问题描述
某项目通过拉摄像机rtsp流转rtmp/http-flv/ws-flv的方案，使用户可以在网页中观看摄像机的视频画面。在 观看视频时偶发出现卡顿现象。
二、卡顿现象分析和解决
此问题涉及的原因较多，所以得考虑各环节的问题可能性，并根据现场实际情况进行处理。整个项目的视频链路为摄像机（rtsp服务器） -> 推流端（将摄像机rtsp转rtmp） -> 流媒体服务器（转协议，将rtmp转为http-flv/ws-flv） -> 外网服务器（提供互联网访问连接的主机电脑，让用户可以在外网观看最终转出来的视频）。
可以看到链路比较多，当出现卡顿问题时需要从摄像机排查到推流端、流媒体服务器......外网再到播放器。我们可以一步步通过ffplay/vlc等播放器播放摄像机rtsp，内网播放http-flv/ws-flv，再到外网播放转出来的流来一步步排查是哪个链路出现问题。
(一)推流端
1.推流端硬件条件限制
使用推流工具（比如FFmpeg）推流（转码） “ 时，码率、帧率或编码档位设置得过高，但硬件条件存在限制（推流软件 所在电脑的 CPU 性能较差），导致编码速度变慢，无法达到流畅播放的帧率要求。 如果推流端所在电脑的整体 CPU 使用率超过80% ，那么视频的采集和编码都会受到影响，无法正常发挥作用；如果其 CPU 使用率达到 100%，那么推流端本身就已经很卡，观众端要有流畅的观看体验显然是不可能的。在Windows上可以使用任务管理器，Linux上使用top命令查看进程的CPU使用率。
解决方法：
尝试降低码率、帧率的设置，检查卡顿现象是否有好转。如果发生好转，可以考虑升级推流端所在电脑的硬件配置；或者不转码仅仅进行转封装 进行推流。
2.系统资源占用
检查推流端 所在电脑后台是否运行了大量的程序，建议删除和停止正在运行的程序，空出资源。
3.推流帧率过低
人眼识别为流畅的视频需要 FPS 每秒 15 帧以上。如果 FPS 低于 10 帧，画面就会出现较明显的卡顿。如无特殊情况，尽量将视频帧率设置在每秒15 帧之上，如果摄像机画面本身变化就很少，如静态画面或PPT 播放等场景，则不受该原因影响 。虽然视频的帧率越高画面流畅感越强，但是帧率超过每秒 30 帧 后，人眼就无法识别出画面的效果，帧率增加也会增加视频传输的带宽成本，建议合理设置该参数。
解决方法：
在推流指令中更改推流的帧率；或者更改摄像机自带配置网页中的设置，在里面更改帧率。
（二）流媒体服务器端
1.GOP缓存功能
为了保证视频的秒开以及降低视频的卡顿，一般的流媒体服务器默认会缓存数秒的数据，这一般叫 GOP缓存功能。比如缓存 180 秒的帧数据 , 任何终端播放的时候都是从 180 秒前进行播放 , 这样就至少保证 不会出现卡顿，但这样做延时会很大。部分流媒体服务器，比如开源的zlmediakit 并没有该功能。
2.自适应码率技术
自适应码率技术可以： 1. 让播放体验更加智能。例如，用户在一个不确定的网络环境下，不知道什么 清晰度最合适，选择高清晰度，卡了；选择低清晰度，画质体验又不好。自适应码率就是要解决这个选 择问题，智能匹配最合适的清晰度，避免用户自己反复去尝试；2. 避免播放卡顿。高清视频，在网络限 速或者更常见的4G 下，网络波动大，自适应码率可以实时地调节清晰度，在保证用户观看更高清晰度的 情况下，避免播放卡顿。
自适应码率技术原理：
第一步，原始的视频资源文件，它可能只有一个比较高的清晰度；
第二步，生产端对视频进行转码和切片，根据播放需要，转码成不同清晰度的码流。一般清晰度越高，
码率越高，文件越大。每个码流都切分成时间对齐的分片，一般是 10s ；
第三步，在转码和切片之后，经过 CDN 节点在网络上进行分发；
第四步，各自适应码率的算法（基于带宽速率、 基于播放器 Buffer 的 BBA 算法 、 MPC 算法 、基于机器
学习）按策略选择需要的清晰度；
第五步：客户端下载这个清晰度的分片文件，进行播放。
3.抗丢包技术
由于网络的不稳定，丢帧的情况时有发生，为了避免花屏，部分播放器会把丢失参考帧的视频丢掉， 其会无法渲染新的数据，这就会导致视频出现卡顿的问题。所以服务端一般会综合运用前向纠错、后向 补偿、丢包补偿技术使得在丢包率极高的环境下也能流畅直播。
（三）播放端
1.播放端硬件条件限制
使用播放器播放音视频时，电脑的cpu或者gpu占用达到100%，意味着电脑正在全力运转，处理器已经没有剩余资源来处理其他任务了。这就可能会导致视频卡顿、画面不流畅等问题。
解决方法：升级播放端电脑硬件，使用更高端的cpu和gpu；降低视频质量，降低视频的分辨率、码率、帧率等参数；关闭其它应用程序。
2.播放器缓冲区过小
一般的网络播放器都会有缓冲区抵抗网络抖动、抵抗解码抖动、避免被动丢帧导致花屏。缓冲区设置得过小，网络抖动时就可能会卡顿。但是缓冲器过大，则会导致内存占用高、播放延时大。
针对网络抖动：大部分播放器是接收缓存后才进行解码显示的，接收缓存的大小也会影响播放的流畅 度。所以可以通过调整接收缓存的大小，减少卡顿的影响。通过计算网络延迟来知道网络抖动的大小， 这样设置合适的缓冲区大小用来存储接收到的数据包。假设一开始网络抖动过大，这时播放器可以创建 一块buffer 用来接收数据，但不及时的送去给解码处理或者渲染处理，而是等待网络抖动大小设置的延 迟时间到了才把buffer 里的数据提供给解码或者渲染。这块 buffer 里含有多个视频帧数据，这样解码器 从buffer 里获得的数据就是时间连续的，这样就不会出现视频忽快忽慢的情况，而是看起来很平滑顺畅。但是使用jitter buffer，渲染的视频就会和源视频有较大的延迟，这是不可避免的。
3.部分播放器特性导致
部分开源播放器比如flv.js本身存在特性（bug），使用追帧策略时，跳帧会有明显卡顿，并且画面不连续。
解决方法：更换更好的播放器，不要用flv.js。
(四）带宽不足
1.上行带宽不足
上行是指从用户设备（如电脑、手机）发送数据到互联网或其他网络的过程。在宽带网络中，上行通常用于上传文件、发送电子邮件、进行视频通话等。 上行带宽 不足或网络发生抖动，导致数据发送速率下降，无法达到流畅播放的帧率要求。 推流端在推流 时会源源不断地产生音视频数据，如果推流端的上传网速太小，那么产生的音视频数据都会被堆积在推 流端所在的电脑里传不出去，上传阻塞导致全部观众（全部播放端）的观看体验都很卡顿 。特别是推流 端所在电脑连接了 wifi ， Wi-Fi 信号受建筑墙体的屏蔽干扰很严重，而一般的建筑很少在装修时考虑好 Wi-Fi 路由器和各个房间的信号衰减问题。可以使用网速测试工具 Speedtest 测试当前网络的上行带宽情 况。
例子：
如下图所示，用Speedtest测到流媒体服务器所在电脑的上传带宽是40.55Mbps
·
但是通过任务管理看到该电脑每秒发送62.2Mbps的数据到互联网上，62.2Mbps > 40.55Mbps，所以就会出现观看视频卡顿现象。
解决方法：
针对上行带宽不足： 向运营商申请更多的带宽； 降低推流码率； 用摄像机的次码流作为输入（相同 环境下，次码流占用的带宽小，具体可进入摄像机配置网页的中调节）； 无人观看不取流处理，当没有对应客户端 / 前端播放视频时让推流端 停止对应的推流，从而节约带宽。
2.下行带宽不足
下行是指从互联网或其他网络接收数据到用户设备的过程。在宽带网络中，下行通常用于下载文件、浏览网页、观看视频等。 下行带宽不足，即观众的下载带宽跟不上或者网络波动较大，例如直播流的码率是2Mbps 的，也就是每秒钟有2M 比特的数据流要下载下来，但如果观众端的带宽不够，就会导致观众端播放体验非常卡顿。 下行不佳只会影响当前网络环境下的观众。解决方法与上行带宽不足的解决方法相同。
