柳州网站推广哪家好,电子商务网站建设与维护第二版,郑州短视频代运营,网站数据库连接失败目录
1、国产化系统概述
1.1、国产化操作系统与国产化CPU
1.2、国产化服务器操作系统
1.3、当前国产化系统的主流配置
2、视频解码花屏与卡顿问题
2.1、视频解码花屏
2.2、视频解码卡顿
2.3、关于I帧和P帧的说明
3、国产显卡处理速度慢导致图像卡顿问题
3.1、视频延…目录
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架构主要也用于服务器方面最新型号是鲲鹏9207nm工艺由台积电代工。 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播放器就做了唇音同步控制而在一些音视频软件中不做唇音同步控制音频和视频来了就解码播放一般视频解码播放速度要明显慢于音频解码播放视频编解码算法及视频播放比音频复杂很多处理时间要长很多一般较容易出现唇音不同步的问题。
3.5、国产化芯片的问题 这个问题也显现了国产化显卡芯片景嘉微显卡和国外顶级显卡芯片AMD显卡的差距无论是性能还是稳定性亦或是成熟度应该都有一定的差距。所以国产化芯片的路还很长国内目前在芯片领域做的最好的还是华为海思无论是功能完备性还是性能亦或是成熟度都是国内顶级的存在。 以前音视频应用领域基本都在用华为海思的主控芯片后来因为被制裁导致华为海思芯片无法生产无法供货只能转投国内二线厂商比如寒武纪和瑞芯微但这些厂商限于技术水平和行业经验在多个方面和华为海思有着明显的差距比如稳定性比较差、性能不足、功能完备性不够、处理问题的速度缓慢等这些我们深有感触。 没办法没法用到华为海思的芯片只能和这些二三流厂商一起去优化和改进他们的芯片这个过程是痛苦的但从长远来看对国产芯片的发展是有很大好处的国产芯片需要大家来支持使用这样才能持续地进行优化、改进和完善。 4、最后 本文从一个非音视频编解码开发者的角度记录了国产化项目中遇到的视频播放问题旨在把这些内容作为音视频基础知识和常识来了解难免会出现不严谨或用词不准确的问题欢迎大家在评论区批评指正也欢迎大家在评论区对相关细节进行补充。 我们开发的是音视频相关的业务软件经常和音视频编解码开发人员打交道时常和他们一起排查各种与音视频相关的问题及软件崩溃问题对音视频领域的基础知识和业务流程比较感兴趣也希望通过与音视频编解码开发同事协同排查问题去接触学习一些音视频相关的知识。
