目录
C++软件异常排查从入门到精通系列教程（专栏文章列表，欢迎订阅，持续更新...）
https://blog.csdn.net/chenlycly/article/details/125529931C/C++基础与进阶（专栏文章，持续更新中...）https://blog.csdn.net/chenlycly/category_11931267.htmlVC++常用功能开发汇总（专栏文章列表，欢迎订阅，持续更新...）https://blog.csdn.net/chenlycly/article/details/124272585C++软件分析工具从入门到精通案例集锦（专栏文章，持续更新中...）https://blog.csdn.net/chenlycly/article/details/131405795开源组件及数据库技术（专栏文章，持续更新中...）https://blog.csdn.net/chenlycly/category_12458859.html网络编程与网络问题分享（专栏文章，持续更新中...）https://blog.csdn.net/chenlycly/category_2276111.html
近些年来，随着国产化进程的持续深入，多个IT厂商都相继推出了支持国产化系统的软件产品与系统，我们也不例外，我们也陆续参与了多个国产化项目，先后推出了支持国产化系统的一整套解决方案。最近在国产化桌面系统中测试国产化软件时，遇到了多个视频编解码及播放问题，我参与了这类问题的讨论与排查，在此做一个详细的记录和总结，也希望能给大家提供一个借鉴或参考。国产化系统中遇到的视频花屏、卡顿以及延迟问题的记录与总结
1、国产化系统概述
本文中的问题出在国产化PC上，所以先来给大家详细介绍一下国产化系统相关的内容。
提到国产化系统，一般主要涉及两大块，一块是国产化操作系统，一块是国产化CPU，这两大块均取得了较大的进展，并涌现了一批国产化厂商。
1.1、国产化操作系统与国产化CPU
目前主流的国产化操作系统主要有麒麟公司的中标麒麟与银河麒麟系统、统信软件的UOS系统等。这些系统厂商均提供了桌面版本和服务器版本的操作系统。这些国产化操作系统均是从Linux系统发展而来，本质上均是Linux系统。
1.1.1、当前国际上主流的CPU架构
当前业界主流的CPU架构有AMD和Intel的X86架构 、华为海思广泛采用的ARM架构 、MIPS架构 、开源RISC-V架构 、还有国产的龙芯LoogArch架构等，如下所示：
其中，X86架构主要占据全球PC桌面和服务器领域大部分市场，PC桌面领域被Intel和AMD的CPU瓜分，服务器领域则大规模使用Intel的i系列高性能CPU和至强服务器专用CPU。
ARM公司的ARM架构则牢牢称霸移动处理器市场，主流的手机CPU厂商高通、华为、三星、联发科等均使用ARM架构。
已经终止开源的MIPS架构，已不复当年之勇，越来越多厂商都选择拥抱更加开放的开源RISC-V架构，甚至连X86架构巨头Intel和AMD都有介入。
龙芯中科（中科院）的国产龙芯LoogArch架构，具有完全自主产权，采用龙芯架构的龙芯CPU取得了长足的进步，逐步缩短与顶级厂商Intel和AMD的差距。纯国产龙芯CPU的研制成功，实现了复兴号高铁100%国产化，让国产重型歼击机歼20的雷达和北斗导航卫星都装上了中国芯！
1.1.2、当前主流的国产CPU
当前主流的国产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（鲲鹏920）。对于国产化服务器系统，除了麒麟、统信UOS和华为欧拉（Eular）系统之外，还可以选择使用腾讯的TencentOS系统以及阿里的龙蜥（Annolis）系统。
多年来，大多数IT厂商的服务器操作系统都会选择开源免费的CentOS系统，但红帽公司之前宣布停止维护CentOS，这就意味着CentOS不再迭代更新，在使用CentOS时遇到系统及内核方面的问题时，也不再有团队去维护和解决了。
为了应对CentOS停止维护带来的窘境，国内的三大IT厂商华为、腾讯和阿里站了出来，相继推出了从开源Linux与开源CentOS演进而来的国产免费开源的服务器操作系统：华为欧拉（Eular）系统、腾讯TencentOS系统和阿里龙蜥（Annolis）系统。这些服务器操作系统在原有的开源系统代码的基础上做了大量的优化与改进，并成立了开源社区，与国内产商一起合作将系统生态发展壮大起来。目前很多IT厂商已经将服务器操作系统迁移到这些国产的系统上，比如不少厂商现在都在用华为的欧拉服务器系统。
此外，腾讯牵头，联合国内多家操作系统厂商，成立了OpenCloudOS社区，致力于推动国产开源操作系统的发展。
OpenCloudOS是于成立的2021年12月22日开源操作系统社区开源操作系统社区。该社区由腾讯与合作伙伴共同倡议发起，是完全中立、全面开放、安全稳定、高性能的操作系统及生态。
OpenCloudOS 沉淀了多家厂商在软件和开源生态的优势，继承了腾讯在操作系统和内核层面超过10年的技术积累，在云原生、稳定性、性能、硬件支持等方面均有坚实支撑，可以平等全面地支持所有硬件平台。
在国外，为了应对CentOS停服，相继推出了两个版本的Linux服务器操作系统，一个是Rocky Linux ，一个是AlmaLinux：
1）Rocky Linux
CentOS的最初创始人格雷戈里·库尔泽(Gregory Kurtzer)，为了实现CentOS的最初目标，创立了企业级开源系统Rocky Linux，同时也是为了向早期CentOS的联合创始人洛基·麦高(Rocky McGaugh) 致敬。目前，Rocky Linux的代码库已经成为 GitHub 上最热门的代码库之一。
2）AlmaLinux
在红帽突然宣布不再维护CentOS后，CloudLinux公司宣布启动替代CentOS的Linux项目，并随后改名为AlmaLinux。AlmaLinux也是一个免费开源的企业级系统，由开源社区维护并管理。
如果大家对这两个系统感兴趣，可以到网上去详细了解一下！
1.3、当前国产化系统的主流配置
当前主流的国产化桌面PC 主要使用中标麒麟/银河麒麟/UOS桌面操作系统 + 飞腾CPU/龙芯CPU的方案。
主流的国产化服务器 则使用中标麒麟/银河麒麟/UOS/欧拉服务器系统 + 龙芯CPU/飞腾CPU/鲲鹏CPU的组合方式。其中，鲲鹏CPU（鲲鹏920）是华为专用的，不对外开放使用的（只用在华为的产品中），是和华为泰山服务器绑定在一起的。要使用鲲鹏CPU，则需要购买华为的泰山服务器，服务器中使用的是华为欧拉系统。
对于国产服务器CPU而言，通过实测，华为鲲鹏CPU的性能要高一些，在一些对性能要求较高的项目中，会选用华为内置鲲鹏CPU和欧拉系统的泰山服务器。
其实对于国产化服务器，除了服务器操作系统和CPU，还有一个基础设施软件，就是数据库 。为了更好的自主可控，我们弃用了之前使用最多的MySQL （虽然MySQL免费开源，但受商业公司Oracle甲骨文控制，有一定的风险），选用了更加开放的高性能免费开源数据库PostgreSQL！
2008年1月，MySQL被发明Java语言的美国Sun Microsystems公司收购。 2009年4月，美国Oracle甲骨文公司收购了Sun Microsystems公司，这样，MySQL就转到了Oracle旗下。目前甲骨文公司一方面提供商业收费版的Oracle数据库，另一方面也在维护免费开源的MySQL数据库。
2、视频解码花屏与卡顿问题
在国产化桌面PC上测试客户端软件时，发现视频解码播放时有明显的花屏问题，这个问题比较严重。当前出问题的国产化桌面PC的主要配置为：银河麒麟系统 + 飞腾CPU + 国产景嘉微显卡（后续问题主要与这个国产景嘉微显卡有关系）。
当前的国产化软件运行在国产化系统中，主要使用开源的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/105747624
在这里，给大家重点推荐一下我的几个热门畅销专栏：
专栏1：（该专栏订阅量已达到400多个，有很强的实战参考价值，广受好评！专栏文章持续更新中，预计更新到200篇以上！）
C++软件调试与异常排查从入门到精通系列文章汇总https://blog.csdn.net/chenlycly/article/details/125529931
本专栏根据近几年C++软件异常排查的项目实践，系统地总结了引发C++软件异常的常见原因以及排查C++软件异常的常用思路与方法，详细讲述了C++软件的调试方法与手段，以图文并茂的方式给出具体的实战问题分析实例，带领大家逐步掌握C++软件调试与异常排查的相关技术，适合基础进阶和想做技术提升的相关C++开发人员！
专栏中的文章均是通过项目实战总结出来的（通过项目实战积累了大量的异常排查素材和案例），有很强的实战参考价值！专栏文章还在持续更新中，预计文章篇数能更新到200篇以上！
专栏2：
C/C++基础与进阶（专栏文章，持续更新中...）https://blog.csdn.net/chenlycly/category_11931267.html
以多年的开发实战为基础，总结并讲解一些的C/C++基础与进阶内容，以图文并茂的方式对相关知识点进行详细地展开与阐述！专栏涉及了C/C++领域的多个方面的内容，同时给出C/C++及网络方面的常见笔试面试题，并详细讲述Visual Studio常用调试手段与技巧！
专栏3：
开源组件及数据库技术https://blog.csdn.net/chenlycly/category_12458859.html
以多年的开发实战为基础，分享一些开源组件及数据库技术！
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: A dvanced 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播放器就做了唇音同步控制），而在一些音视频软件中不做唇音同步控制，音频和视频来了，就解码播放，一般视频解码播放速度要明显慢于音频解码播放（视频编解码算法及视频播放比音频复杂很多，处理时间要长很多），一般较容易出现唇音不同步的问题。
3.5、国产化芯片的问题
这个问题也显现了国产化显卡芯片（景嘉微显卡）和国外顶级显卡芯片（AMD显卡）的差距，无论是性能，还是稳定性，亦或是成熟度，应该都有一定的差距。所以，国产化芯片的路还很长！国内目前在芯片领域做的最好的还是华为海思，无论是功能完备性，还是性能，亦或是成熟度，都是国内顶级的存在。
以前音视频应用领域基本都在用华为海思的主控芯片，后来因为被制裁导致华为海思芯片无法生产无法供货，只能转投国内二线厂商，比如寒武纪和瑞芯微，但这些厂商限于技术水平和行业经验，在多个方面和华为海思有着明显的差距，比如稳定性比较差、性能不足、功能完备性不够、处理问题的速度缓慢等，这些我们深有感触。
没办法，没法用到华为海思的芯片，只能和这些二三流厂商一起去优化和改进他们的芯片，这个过程是痛苦的，但从长远来看，对国产芯片的发展是有很大好处的，国产芯片需要大家来支持使用，这样才能持续地进行优化、改进和完善。
4、最后
本文从一个非音视频编解码开发者的角度记录了国产化项目中遇到的视频播放问题，旨在把这些内容作为音视频基础知识和常识来了解，难免会出现不严谨或用词不准确的问题，欢迎大家在评论区批评指正，也欢迎大家在评论区对相关细节进行补充。
我们开发的是音视频相关的业务软件，经常和音视频编解码开发人员打交道，时常和他们一起排查各种与音视频相关的问题及软件崩溃问题，对音视频领域的基础知识和业务流程比较感兴趣，也希望通过与音视频编解码开发同事协同排查问题去接触学习一些音视频相关的知识。