国产化系统中遇到的视频花屏、卡顿以及延迟问题的记录与总结

1、国产化系统概述

1.1、国产化操作系统与国产化CPU

1.2、国产化服务器操作系统

1.3、当前国产化系统的主流配置

2、视频解码花屏与卡顿问题

2.1、视频解码花屏

2.2、视频解码卡顿

2.3、关于I帧和P帧的说明

3、国产显卡处理速度慢导致图像卡顿问题

3.1、视频延时和卡顿原因分析

3.2、SDL2库跑在景嘉微国产显卡上效率很低

3.3、采用抽帧播放的方式来解决这类问题

3.4、关于音视频播放中的唇音不同步问题

3.5、国产化芯片的问题

4、最后

VC++常用功能开发汇总（专栏文章列表，欢迎订阅，持续更新...）https://blog.csdn.net/chenlycly/article/details/124272585C++软件异常排查从入门到精通系列教程（专栏文章列表，欢迎订阅，持续更新...）https://blog.csdn.net/chenlycly/article/details/125529931C++软件分析工具从入门到精通案例集锦（专栏文章正在更新中...）https://blog.csdn.net/chenlycly/article/details/131405795C/C++基础与进阶（专栏文章，持续更新中...）https://blog.csdn.net/chenlycly/category_11931267.html 近些年来，随着国产化进程的持续深入，多个IT厂商都相继推出了支持国产化系统的软件产品与系统，我们也不例外，我们也相继参与了多个国产化项目，先后推出了支持国产化系统的一整套解决方案。最近在国产化桌面系统中测试国产化软件时，遇到了多个视频编解码及播放问题，我参与了这类问题的讨论与排查，在此做一个详细的记录和总结，也希望能给大家提供一个借鉴或参考。

1、国产化系统概述

本文中的问题出在国产化PC上，所以先来给大家详细介绍一下国产化系统相关的内容。

1.1、国产化操作系统与国产化CPU

提到国产化系统，一般主要涉及两大块，一块是国产化操作系统，一块是国产化CPU，这两大块均取得了较大的进展，并涌现了一批国产化厂商。目前主流的国产化操作系统主要有麒麟公司的中标麒麟与银河麒麟系统、统信软件的UOS系统等。这些系统厂商均提供了桌面版本和服务器版本的操作系统。这些国产化操作系统均是从Linux系统发展而来，本质上均是Linux系统。

主流的CPU则有龙芯CPU（基于国产自研的LoogArch架构）、飞腾CPU（基于ARM架构）、兆芯CPU（基于授权的X86架构）以及华为鲲鹏CPU（基于ARM架构）等，这些CPU厂商也提供了桌面版本和服务器版本的CPU。下面给出几个主流国产化CPU的信息：

1）龙芯CPU：早期采用MIPS架构，后来自研了LoogArch架构，目前最强的一款是龙芯3A5000系列，12nm工艺，早期由意法半导体代工，后来12nm的交给台积电代工。

2）飞腾CPU：采用ARM架构，有桌面版，也有服务器版，最新桌面版型号是D2000系列，采用16nm工艺，由台积电代工。

3）华为鲲鹏CPU：采用ARM架构，主要也用于服务器方面，最新型号是鲲鹏920，7nm工艺，由台积电代工。

4）兆芯CPU：采用X86架构，目前最强的是KX-U6780A 处理器，16nm工艺，由台积电代工。

5）海光CPU：采用X86架构，主要用于服务器方面，最新的是海光7000系列，14nm工艺，代工方是三星、格芯。

6）申威CPU：采用Alpha架构，后面又自研了SW指令集，目前最新的是申威SW26010系列，采用28nm工艺，主要用于超级计算机，由中芯国际代工。

1.2、国产化服务器操作系统

对于国产化服务器的部署，主要使用内置国产化系统和国产化CPU的长城服务器。华为也提供了支持国产化的泰山服务器，该系列服务器主要使用华为自研的欧拉（Eular）服务器操作系统以及华为鲲鹏CPU。对于国产化服务器系统，除了麒麟、统信UOS和华为欧拉（Eular）系统之外，还可以选择使用腾讯的TencentOS系统以及阿里的龙蜥（Annolis）系统。

多年来，大多数IT厂商的服务器操作系统都会选择开源免费的CentOS系统，但红帽公司之前宣布停止维护CentOS，这就意味着CentOS不再迭代更新，在使用CentOS时遇到系统及内核方面的问题时，也不再有团队去维护和解决了。

为了应对CentOS停止维护带来的窘境，国内的三大IT厂商华为、腾讯和阿里站了出来，相继推出了从开源Linux与开源CentOS演进而来的国产免费开源的服务器操作系统：华为欧拉（Eular）系统、腾讯TencentOS系统和阿里龙蜥（Annolis）系统。这些服务器操作系统在原有的开源系统代码的基础上做了大量的优化与改进，并成立了开源社区，与国内产商一起合作将系统生态发展壮大起来。目前很多IT厂商已经将服务器操作系统迁移到这些国产的系统上，比如不少厂商现在都在用华为的欧拉服务器系统。

1.3、当前国产化系统的主流配置

当前主流的桌面国产化PC主要使用中标麒麟/银河麒麟/UOS桌面操作系统 + 飞腾CPU/龙芯CPU的方案。

主流的国产化服务器则使用中标麒麟/银河麒麟/UOS/欧拉服务器系统 + 龙芯CPU/飞腾CPU/鲲鹏CPU的组合方式。其中，鲲鹏CPU是华为专用的，不对外开放使用的（只用在华为的产品中），是和华为泰山服务器绑定在一起的。要使用鲲鹏CPU，则需要购买华为的泰山服务器，服务器中使用的是华为欧拉系统。

对于国产服务器CPU而言，通过实测，华为鲲鹏CPU的性能要高一些，在一些对性能要求较高的项目中，会选用华为内置鲲鹏CPU和欧拉系统的泰山服务器。

2、视频解码花屏与卡顿问题

在国产化桌面PC上测试客户端软件时，发现视频解码播放时有明显的花屏问题，这个问题比较严重。

当前的国产化软件运行在国产化系统中，主要使用开源的SDL2去实现视频的绘制渲染，在Linux国产化系统平台上，SDL2内部使用opengl去进行渲染。

2.1、视频解码花屏

通过查看打印日志发现，USB摄像头采集出来的视频图像有明显的丢帧问题，对视频进行解码播放时默认使用强解模式（视频丢帧时不等待I帧直接解码播放），因为采集出来的图像有丢帧，所以出现了花屏问题。将当前使用的USB摄像头插到Windows PC上，使用amcap工具查看该摄像头的视频采集参数，发现该摄像头内部采集到图像后会对图像数据进行编码压缩，支持MJPG和H264两种编码格式，如下所示：

出问题的场景下，使用的是默认的H264编码格式，这种编码格式下输出的视频数据有丢帧的问题。

2.2、视频解码卡顿

为了解决这个由视频丢帧引起的花屏问题，将强解模式改成等待I帧播放模式。在等I帧播放模式中，如果发现视频有丢帧，则不会解码绘制，直到收到新的I帧时才会绘制。改成等待I帧模式后，虽然没有花屏问题了，但有严重的视频卡顿问题。因为视频有丢帧时，视频图像不再解码显示，直到收到新的I帧才会绘制，在这个时间段内始终显示的是之前的图像，收到新的I帧才会绘制新的图像，所以导致了该时间段的视频卡顿问题。远端在接收本端发出去的视频数据时发现丢帧，会主动向本端请求I帧，但这个请求I帧只是临时补救手段，在频繁丢帧时还是会有明显的卡顿问题。

导致视频花屏和卡顿的根本原因，是USB摄像头输出的视频有频繁的丢帧导致的，所以要解决这两个问题，还是要从源头（摄像头）上找解决办法。于是尝试将摄像头的视频编码格式改成MJPG，重新运行后发现该编码格式下输出的图像质量比较好，没有丢帧问题，这样解码播放视频时就不再有花屏、卡顿的问题了。

2.3、关于I帧和P帧的说明

I帧是帧内编码，一个I帧就是一张完整的图像；P帧是帧间编码，P帧中存放的是相对上一帧变化的内容，在绘制每一帧图像时需要将当前的P帧和上一次叠加后的完整的图像再叠加，才能形成当前完整的一帧图像（叠加获取完整的视频图像后再去绘制）。每次叠加后的完整图像要保存在内存中，以便收到下一个P帧时能叠加出完整的图像。

如果中间有P帧丢了，收到下一个P帧后可能就无法叠加出完整的图像了，在强制解码的模式下，可能就会出现花屏的问题。对于等待I帧模式，视频帧数据接收端发现有丢帧，则停止绘制图像，等收到新的I帧才进行绘制。并且视频接收端在发现有视频丢帧时，会主动像视频发送端请求I帧，以便能尽快收到I帧，尽快将新的图像绘制上去，保持图像播放的连续性。

关于I帧和P帧的详细说明，可以参见这篇文章：

H264 (一) I/P/B帧 GOP/IDR/等参数https://blog.csdn.net/weixin_39369053/article/details/105747624https://blog.csdn.net/weixin_39369053/article/details/105747624

3、国产显卡处理速度慢导致图像卡顿问题

本来以为上述问题到此就结束了，结果后来经过观察发现，视频图像还是有卡顿问题，而且有明显的延时。

3.1、视频延时和卡顿原因分析

通过打印得知，从接收到视频数据（接收到的是远端编码压缩后的视频数据），到解码绘制完成大概需要好几秒钟，这个延时有点夸张了（对着摄像头挥手就能看出来视频有明显的延时）！通过分析代码发现，延时可能是因为显卡性能不足导致解码绘制速度慢导致的，而视频卡顿可能是由视频丢帧导致的。

那为什么会出现视频帧数据丢失呢？进一步分析代码找到了答案，视频数据处理模块开启了两个线程，一个线程用于接收视频数据帧，收到后放到一个缓冲队列中，另一个线程从缓冲队列中取出视频数据帧（编码压缩后的视频数据），对数据先进行解码，然后将解出的视频数据绘制到视频窗口中（在视频窗口中显示视频），两个线程操作数据队列的效果图如下所示：

因为显卡性能有限，影响到了解码显示的速度（绘制视频图像时底层会用到显卡去渲染绘制），导致处理解码显示的线程速度很慢，同时视频帧接收线程一直在不断地接收数据，而队列长度是有限的（比如存放帧数据的个数上限为100多帧，或者缓冲队列的内存是有限的），导致队列中的视频帧数据来不及被处理就被丢弃掉了（丢弃老的视频帧数据，为新的视频帧数据腾出存放空间）。因为有视频帧丢失，当前使用的是等待I帧解码模式，导致一小段时间内不再解码播放，直到收到下一帧才播放绘制，所以产生了视频卡顿。

此处是如何知道解码播放线程处理速度慢的呢？其实很简单，添加时间相关打印日志即可看出来。在日志打印系统中，一般每条打印中都会携带时间信息的，方便分析问题，比如方便查看代码执行时长和速度的、快速查看发生异常时间点附近的打印日志等。

3.2、SDL2库跑在景嘉微国产显卡上效率很低

之前在一个国产项目中也遇到视频解码播放有明显卡顿延迟的问题，当时问题排查了很久，最后怀疑是显卡性能不足导致的。当时的场景是，客户环境中几乎所有的国产化电脑都没问题，但有一台国产化电脑会有这个视频卡顿延时问题。后来客户的国产化电脑提供商主动给客户更换了显卡，就不再有问题的。这台出问题的国产化电脑，之前使用的景嘉微公司的国产显卡，后来换成AMD的显卡就没问题了，看来国产的显卡和顶级的AMD显卡在性能上还是有明显的差距的！

对于这个视频播放延时卡顿的问题，如果好复现，在公司的测试环境中应该早就暴露出来了（测试人员在测试过程中应该会复现出来），但之前一直没有出过这个问题。通过客户的这个问题案例，我们知道为啥在公司测试环境没有暴露这个问题的原因了，因为我们公司测试环境中之前用的国产化电脑中的显卡都是AMD的。而此次我们测试环境中遇到的视频播放延时卡顿问题，是因为这次使用的国产化设备比较特殊，使用的是景嘉微的国产JM7200显卡，所以出现了和项目客户一样的问题。

在Terminal命令行中使用lshw命令即可查看当前国产化机器上使用的显卡信息，具体的命令格式为：Ishw -c display，比如AMD的显卡信息如下：

description: VGA compatible control
product: Caicos [Radeon HD 6450/7450/8450R5 230 0EM] [1002:6779]
vendor: Advanced Micro Devices, Inc. [AMD/ATI] [1002]

景嘉微的显卡信息如下：

description: VGA compatible controller
product: JM7200 [731:7200]
vendor: JingJla Micro, Inc. [JJM] [731]

对应的景嘉微显卡型号为JM7200，出问题的这台电脑用的就是景嘉微的显卡，结合之前项目中遇到的类似的情况，基本可以断定是当前用于视频绘制渲染的SDL2开源库在景嘉微显卡上运行效率低导致的。

从运行现象上看，应该是开源的SDL2在景嘉微国产显卡上运行效率低导致的，可能是景嘉微对Linux上的OpenGL框架支持不好，或者景嘉微显卡驱动存在问题，或者是景嘉微显卡性能不够，亦或是SDL2开源库对国产化显卡的支持不够，具体是哪种原因，后面需要花时间进行研究。也可以将这个问题反馈给景嘉微公司，让他们给分析一下原因！

3.3、采用抽帧播放的方式来解决这类问题

当前的问题是因为解码播放线程处理速度明显慢于视频数据接收线程（慢很多），导致视频帧数据缓冲队列满，导致部分较早收到的、还未来得及处理的视频帧数据从队列中踢出丢弃了：

解码播放线程执行速度慢，是因为景嘉微国产显卡的性能不足导致的。

为了解决当前的视频卡顿延时问题，讨论后决定采用抽帧播放的办法，如果视频帧数据缓冲队列达到某个上限（设定一个阈值，比如10）时，就开启抽帧播放模式，每收到两帧数据，只播放一帧，降低对显卡处理能力的占用。可以根据测试的效果的去调整这个队列上限阈值，以达到一个比较好的播放效果。但目前这种处理方法只是一种规避的方法，不是根本的解决办法，但对于这类特殊的国产化机器，让他们将显卡更换成非国产的AMD显卡似乎也不太现实，也只能使用这种折中的办法。

此外，抽帧播放视频也会有一定的问题，比如视频帧率较低（可能是网络不好导致的）时，比如帧率只有10帧，只播放5帧视频，也会出现图像不连续卡顿的问题。但这也是没办法的事情，抽帧播放是为了保证视频播放的实时性，实时性比视频卡顿更重要。

3.4、关于音视频播放中的唇音不同步问题

其实还存在另一个问题，即唇音不同步的问题，因为视频播放线程执行的比较慢，音频播放线程执行的很快，导致视频播放速度明显慢于音频播放速度，如果不对音频和视频做同步播放的控制，就可能会出现唇音不同步的问题。

这个唇音同步的问题，在不同的应用场景中关注度是不一样的。比如在视频播放器和直播领域，比较会关注视频和声音，如果出现唇音不同步的问题，看着会很难受，体验会很差，比如我们在看电影视频时，如果唇音不同步，看着会很痛苦。但在视频会议中，更注重的是各个参会方的语音交流，视频关注度不是非常高，即使出现唇音不同步的问题，也是可以忍受的。但如果将会议中的视频录制成视频文件，如果录制的视频中出现唇音不同步，则看着会很难受。

所以在很多播放器中会根据时间戳进行严格的唇音同步控制（开源FFmpeg中的ffplay播放器就做了唇音同步控制），而在一些音视频软件中不做唇音同步控制，音频和视频来了，就解码播放，一般视频解码播放速度要明显慢于音频解码播放（视频编解码算法及视频播放比音频复杂很多，处理时间要长很多），一般较容易出现唇音不同步的问题。