本内容由系统网小编为大家分享，Windows系统安装教程、办公系统、软件怎么使用、软件使用教程、办公软件攻略等信息。

目录

一 播放卡顿

二 首开慢

三 延时高

四 音画不同步

5黑色屏幕,鲜花屏幕,闪光屏幕

六 播放闪屏

7.播放噪音、噪音和反馈

八 拖动不准

一 播放卡顿

卡登的本质在于玩家每秒渲染的帧数太少,并且每秒显示的帧数少于25帧(人类视觉特征的体验值),可能是因为:

1视频流显示时间标记PTS问题

在编码流中,播放器通常严格地与音频视频PTS同步,如果在编码流中发生PTS错误,当然会影响播放屏幕的渲染时间。例如,第15010016070段。。。PTS具有逆转现象。玩家的主钟是单调的渐进的,当随后的视频帧比当前主钟小的时候,说明视频显示慢了，玩家将完成缺失的帧处理,结果的视频帧速率远低于编码流中的视频帧速率,从而产生卡顿现象。

2 网络带宽不足

码流本身没问题的话，接下来就是网络传输这一块了。直播出现卡顿，主播 -> CDN -> 观众三个端都可能是问题的源头：

锚杆端的网络坏,导致上游流动不稳定

服务端线的质量很差,导致分配不稳定

观众端的网络坏了,导致下游抽水不稳定

网络性能测试工具: ping, iperf, 请检查一下.

播放设备性能不足

越高清的码率，解码的要求越高,许多手机都不能支持720P或者1080P视频解码。尤其是许多低端Android手机,因此,实际解码播放的帧速率远低于实际视频编码流的帧速率。从而产生卡顿。

解决办法如下:

1).硬度是优先,GPU加速是最优先

2.如果有多个编码流,尽可能在低端机上选择低编码流

(三)增加缓冲区有助于缓解因解码不稳定性引起的卡顿

本文福利，C++音频视频学习包技术视频内容包括(语音视频开发,面试问题,FFmpeg,webRTC,rtmp,hls,rtsp,ffplay,srs)↓↓↓↓↓↓ 请参阅下文文章的底部下载

二 首开慢

第一次缓慢的性能:在点击播放后,播放屏幕需要几秒。

1点击播放,从服务器获取播放地址

播放视频，第一件事就是获取播放地址，大多数直播 App，主播的播放地址是由 App 向服务端发 HTTP GET 请求才能拿到的，获取播放地址有2种方法：

1)当视频在列表中时,应用程序拉动

2)用户点击视频并跳到播放界面 - http请求太慢,不良体验

2 DNS 解析慢

不同的再生域,DNS分析是快速和缓慢的,加上DNS分析服务的缓冲策略,在没有本地缓冲的域名,将逐步向更高域名服务器查询域名,因此再生域名分析的时间消耗将对第一个启动产生小的影响。

为了有效降低 DNS 解析对首开的影响，我们可以提前完成播放域名->IP 地址的解析，并缓存起来，播放的时候，直接传入带 IP 地址的播放地址，从而省去了 DNS 解析的耗时。

3 播放策略原因

播放开始时间的定义是从点击播放到屏幕的第一帧所花费的时间,所以我们需要尽一切可能来加快播放的进度。 在许多侧向的玩家中,一些缓冲策略被用来减少卡片,并且当足够的数据被缓冲后,它被发送回解码的播放。

为了加速最初的播放效果,需要对播放缓冲策略进行一些调整。如果第一个帧没有渲染,不要做任何缓冲,直接发送到解码器去解码播放,这样你就可以保证没有由“主动”缓冲引起的初始延迟。

4 播放参数配置

所有基于 ffmpeg的玩家,avformat_find_stream_info函数需要很长时间。这增加了最初的开放时间,该函数的主要功能是读取特定节点的编码数据。分析代码流的基本信息,例如,编码信息、时间、编码率、帧率等。它通过两个参数来控制它的读取数据的大小和持续时间,一个是探测,一个是 analyzeduration。

减少 probesize 和 analyzeduration 可以有效地减少 avformat_find_stream_info 的函数耗时，从而加快首开，但是需要注意的是，设置太小可能导致数据读取不足,因此,无法分析编码流信息,导致播放失败，或者只有声音,没有视频,只有视频没有音频问题。

5 服务端原因

当播放端的优化达到极限时,剩下的快速和缓慢的第一次启动是决定性的因素是服务端,服务端的哪些方面主要影响到第一次启动?

1） 冷热流

当你去附近的边缘服务器节点拉取某个流的时候，如果最近没有任何人从该服务器拉过这个流，那么这台服务器就需要逐级向源头拉流，而且该服务器还需要进行 GOP 缓存，从而产生比较大的首开延时。

2)边缘节点的距离

客户端越接近服务器,数据就越快被传输,而且数据就越快被打开。

3)服务器响应速度

影响服务器响应速度的一个因素是服务器的协议层优化,另一个因素是服务器的负载和性能,服务器的当前负载越大,响应自然就越慢。

本文福利，C++音频视频学习包技术视频内容包括(语音视频开发,面试问题,FFmpeg,webRTC,rtmp,hls,rtsp,ffplay,srs)↓↓↓↓↓↓ 请参阅下文文章的底部下载

三 延时高

延时高问题分析

让我们看看哪些模块可能引起延迟:

1)图像处理延迟,例如屏幕切削、美容、特殊效果处理

2)视频编码/解码延迟

3）网络传输的延时

4)业务代码中的缓冲区

一般图像处理、数据拷贝、编解码带来的延时，都是 ms 级别的，真正会产生比较大延时的地方，一个是互联网上的网络传输延时，另一个就是业务代码中的缓冲区了。

1 编码延时

许多人可能不知道H.264解码器通常在显示之前缓存某些视频帧,对于具有176×144的QCIF分辨率的视频,16帧通常是缓存的。对于720P视频,5帧被缓存。第一帧读,这是一大拖延。视频中的B帧的解码取决于视频帧前后,会增加延迟。Codec一般具有低延迟优化开关,对H来说,它的效应在264中尤为明显。

如果使用了 FFmpeg，降低「-probesize 」和「 -analyze duration」参数的值，这两个值用于视频帧信息监测和用于监测的时长，这两个值越大对编码延迟的影响越大。

网络传输延时

数据在网络上传输，通过多级服务器从一个节点转移到另一个节点,不可避免地会有物理上的延误,下面的表给出了光纤网络数据传输的理论时间(实际场景的延迟通常比此长得多,因为它涉及带宽 、 网络震动和其他干扰:

业务代码中的缓冲区

商业代码中的缓冲器主要是 push 端的缓冲器和 play 端的缓冲器,一个30fps的视频流,缓冲器每30帧的延迟增加1秒,那么他们如何生成缓冲器数据?

数据如何在推销端积累?

采集 -> 编码 -> 数据发送 -> 服务器

当网络产生抖动的时候，数据发送会因此减慢，产生一定的阻塞，从而导致这些数据会被积累在了推流端的发送缓冲区中。

游戏结束时数据如何积累?

服务器-> 数据接收 -> 解码 -> 渲染

当网络产生抖动的时候，服务器的数据无法及时地传输到播放端，而由于 TCP 协议的可靠性，所有的数据都会被服务端积累起来，在网络恢复良好的时候，会快速传输到播放端，这些数据会被动地积累在接收缓冲区中。

如何消除企业缓冲区累积延迟?

当网络恢复良好时, push端的发送缓冲器可以迅速发送出去,消除这种累积延迟。

播放端的接收缓冲器可以通过丢失帧或加速播放来快速消耗缓冲器中的数据,从而消除累积延迟。

协议延时

标准广播协议通常有RTMP,HLV，HLS 三种，一般RTMP/HLV协议延迟1至3秒,HLS协议广播的延迟将更大,关注延迟的现场应用,首都地区选择RTMP/HLV协议,这些协议都基于tcp协议,tcp 协议的多个特性导致其延时明显要高于基于 udp 的私有协议，主要有如下方面：

•三手建立联系

• ACK 机制

• 丢包重传

因此,如果你想解决实时延迟问题,你必须转换到基于UDP的私有协议来传输数据。

四 音画不同步

对于播放器而言，它判断一帧视频和一帧音频是否要在同一个时间渲染和播放，依靠的完全是该数据携带的时间戳信息。

如果内容的生产端给音视频数据打的时间戳本身就有问题的话，播放器也往往无能为力了，因此，音画不同步问题，更多的时候，应该从生产端去排查原因。

1 采集源距离太远

如果音频源离麦克风太远,那么摄像机在屏幕后会收集时间标记,并且它必须比麦克风在给音频的同时收集时间标记要小得多,因此会有音频图像同步的问题。

解决方案: 音频源尽可能接近麦克风设备.

2采集设备内部问题

相机和麦克风通过硬件上的多个信号处理模块收集音频视频。如果处理时间滞后不稳定,输出数据可能不稳定,导致应用程序层的时间标记获取错误,导致音频图像不同步。

解决方案:只有很少的硬件/机器类型,并且需要根据获取参数(例如采样率)进行一些 Jitter 抖动修正。

3未使用购买时间邮票

如果获取的时间标记在随后的时刻被修改,有很高的可能的音频视频没有同步问题。

•音频视频算法处理模块

比如：视频经过美颜、编码后，重新更新为了处理后的的时间戳。

缓冲区的不同步骤

在多向程序中,一些帧缓冲器经常被共享在不同的线程之间,缓冲器可以引起音频视频相关性的变化。如果数据被从缓冲器中删除,原来的时间标记被丢弃,新的当前时间被重新使用,那么肯定有问题。

网络传输的不同步骤

由于网络传输的延迟、数据包的丢失等,同时的音频和视频数据包不会在同一时间到达。如果在接收数据后再次按当前时间标记,肯定会有非同步的问题。

时间印有逆转或干扰

如果时间邮票回来,这样的流，这会使玩家有一张纸板,因为主机的主钟通常是单调和指数的,当视频帧小于主钟出现时,一般会做丢弃处理，屏幕没有更新,但音频仍然播放,这会导致声音和屏幕不匹配的问题。

解决方法:检测推力端时标是否是单调线性指数,或服务端是否有一个凸时标,该时标已被修改以引起逆转。

5 播放端性能问题

例如, 低分辨率1080PHD流的低端计算机,解码时不及时可能有问题,导致一些视频解码完成,比当前的音频钟慢得多,只能丢弃，因此,屏幕更新不及时,无法匹配正在播放的音频,这导致了声画的非同步现象。

解决方案: 使用硬分辨率, 选择较低的清洁编码, 增加播放缓冲, 等.

6 马赛克严重

Masec主要指屏幕上许多类似于方块的图像,导致屏幕的一部分或整个画面不清晰。

7视频编码参数配置原因

视频的质量取决于它的编码的质量,越严重压缩,越严重图像丢失,越多 mozaic。

编码器的五个最重要的参数是图像质量、编码率、帧率、GOP大小和编码控制。

图像质量水平:H.264有四个质量水平,Baseline profile，Extended profile，Main profile，High profile。级别越高，压缩的效果越好，但算法复杂度更高，导致功耗也更高。

编码:决定视频压缩的程度,编码越低,信息就越丢失,图像质量就越差。 不过,优点是使用的网络带宽相对较小,在互联网上传输也比较容易,而且获取卡也不容易。

帧率：决定了视频的流畅性，帧率越高，视频越流畅，但每秒钟编码器要处理的数据量也就越大，同等码率下压缩出来的视频质量就越差。

GOP大小: 确定视频的延迟,GOP越小,延迟越小,但GOP大小的问题是关键帧数增加,数据量增加,所以压缩的视频质量在相同的系数上增加。

代码控制方法:一般编码器有固定编码率(CBR)和动态编码率(VBR)两种代码控制方法,前者是指码率优先，为了确保编码率尽可能稳定,会主动降低画质，所以很容易生病,后者是指画质优先，会优先保证画质，减少马赛克，但码率会浮动很大。

当然，还有一个重要的因素，就是编码器本身的实现质量，软编一般可以保证在不同手机上效果一致，而硬编则完全依赖手机所使用的硬件平台了。

8推荐编码器参数配置

一般直播场景中，考虑到手机的性能和电耗,标准图像质量水平是基线 профил,GOP通常设置为1到3s。帧速率通常在15到24帧之间。而码率的配置，然后必须根据推力的决议作出决定,以下图示了建议的分辨率与编码配置关系:

简言之,关于视频编码和拼图之间的关系,我们只需要记住一个原则:发送到编码器的数据越多,编码的压缩越严重,图像信息就越丢失,数据解码后就越创建拼图。

9 图像尺寸原因

一般摄像机收集的图像的分辨率,最后推力尺寸可能不完全匹配,当摄像机的分辨率大于推力大小时,你得先剪掉屏幕,当摄像机的分辨率低于推力大小时,然后你需要先伸展屏幕,然后将压缩编码到编码器中.

例如：小尺寸的画面（比如：640 x 480），拉伸到大的尺寸（比如：1280 x 720），则很容易会产生模糊和马赛克，这样的画面再送入编码器中编码，无论怎样配置都无法再改善已经产生的马赛克了。

因此,为了减少镶嵌,我们必须确保摄像机的分辨率大于最终冲动的分辨率。

10 客观条件原因

如果锚在非常黑暗的环境中,编码器本身的图像质量不会特别好,因此在同样的条件下, mosaic也会相对严重。

同样，如果拍摄的是剧烈晃动的画面，剧烈变化的画面信息量也要大很多，因此，编码的复杂度会明显增大，如果要保证码率不会浮动太大，就必然要降低输出的图像质量，从而产生马赛克现象。

如果直播应用是主打这种光线暗的场景或者剧烈运动的画面场景的话，为了降低马赛克，可以考虑适当将编码参数配置得高 一点（比如：码率高一点，帧率低一点等等），以抵抗环境因素带来的影响。

11 关键帧丢失

还有一种马赛克现象，是由于视频流中丢失了关键帧，导致播放器解码后花屏，从现象来看有点像马赛克，但实际上跟上面讨论的不是同一个问题。

5黑色屏幕,鲜花屏幕,闪光屏幕

黑屏、花屏、闪光屏等,可能有问题在推杆上,这也可能是玩家的问题,遇到这些现象，我们首先想使用一个不同的玩家(如VLC,(ffplay)尝试,如果出现同样的问题,其中很大一部分是关于流动本身,反之，这可能是玩家的问题。

1 播放黑屏

现象:屏幕是黑色,没有图像,但有声音。

2Acrobat末端摄像头限制问题

无论 Android 还是 iOS，App 使用摄像头都是需要申请授权的，特别是 Android 6.0 以后，如果 App 层面不做专门的处理的话，很可能出现摄像头权限被禁用的情况。

如果应用程序没有获得摄像头的权限,视频无法成功捕捉,导致只有音频数据被抽出。

解决方案:应用程序级别必须小心处理许可问题,如果发现没有获得相应的许可,则禁止广播。或者重复提醒锚点给予许可.另外，你可以问一下,是否有摄像机预览屏幕供有问题的锚,如果应用程序没有权限,是没有预览画面的。

3 主播端编码失败

视频数据采集到后，下一步就是经过编码器，由于参数配置或者某些机型的硬编兼容性问题，很可能数据送入编码器后，编码失败，并无输出，从而导致没有视频数据送入到推流模块。

解决方案:一般驱动器SDK统计驱动器的实时视频帧速率,CDN服务器也有一些帧速率监控,因此，如果这些统计数据被发现,阈值框架率为0,同时,确信没有收集任何数据,这就是编码器的一半原因,您可以尝试查看下一个机器类型的日志来查看具体的错误信息。

4 视频解码失败

当播放器遇到不支持的视频格式或数据内容/格式异常时,解码失败,导致无解码的视频输出。

针对不支持的格式：

•事先知道播放器本身支持的音频和视频格式,如H.264、mp4v、aac等,以避免不支持的格式

•玩家本身遇到的硬或软分辨率故障应被报告为日志错误,或应将异常抛出应用程序层,以警告用户

对于视频数据内容错误,必须对编码流文件本身进行分析。数据内容错误导致的常见解码失败如下:

•向解码器发送的帧数据是不完整的

•H.264视频编码,缺少必要的信息标题,如SPS、PPS

• iOS 的 VideoToolbox 解码，只支持 avcc 方式打包的 H.264 数据

•一些硬编译的Android机器的数据还有额外的鼻头

• 其他等等

代码流的第一个半数是没有视频的音频

这种情况，超过一半的编码流来自HLS芯片,当锚在推向相同的地址时,第一个半数只推了音频(可能摄像头的权限被禁了,也可以选择纯音频驱动器等),同时,我们把录像带的音频流放进去,那么，由服务端的HLS芯片生成的文件,这就是会发生的事情。

ffmpeg-based player在视频分析后首先解码了编码器,因此通常只有音频或视频播放为这个编码器流发生。

解决方法:尽可能从应用程序端避开这种使用,修改玩家的代码,并以兼容的方式处理此代码流。

6 播放花屏/绿屏

现象:在播放屏幕上图像被干扰,有较大面积的异常颜色的方块,或绿色屏幕现象

7由此导致的参考帧丢失

264代码流中有三个类型的帧:I、B和P帧;I帧是关键帧;B帧是二进制预测插值编码帧;P帧是前瞻预测编码帧。

I 帧由于是帧内压缩，因此可以独立解码播放，而 B 帧，一旦丢失了 I 帧或者后面的 P 帧，则会解码失败，而 P 帧一旦丢失了前面的 I/B/P 帧，也会导致解码失败。

由于缺少参考帧导致的解码失败,通常会出现花窗现象,花窗的严重程度取决于缺失参考帧对即将解码的框架的重要性。

那么在什么情况下你会失去参考框架?

首先,在运行/播放代码级别上,小心不要在编码后和解码前丢弃视频帧数据,但在实际场景中,不可避免地会发生以下情况:

•网络坏了,编码后的数据无法发送

•系统内存低,无法在队列中处理更多的帧数据

因此，在这种情况下,不得不丢帧的话，最合理的策略是一次失去整个GOP,也就是说,一旦你开始失去一个I帧,所以,在遇到下一帧之前,所有的视频帧,均丢弃掉，这有效地防止玩家最终产生解码屏幕。

玩家没有从关键帧中解码

该原则仍然如上所述,除非解码从关键帧开始,否则它将不可避免地导致由于丢失参考信息而解码屏幕。

因此,无论在第一播映中还是在网络重新连接后,播放器应该决定第一帧视频是否是一个关键帧,如果不是,它应该等到第一帧关键帧到达之前,然后把它送回解码器。

9编码流中的视频大小的变化

很多直播 App，水平活和垂直活,采用不同的推力大小,当锚点从垂直屏幕转向水平屏幕时,如果你同时不更改转发地址,观看者拖动的流将出现在视频大小变化的中间,例如: 从848x480到 1280x720,等等。

玩家需要在实时检测,如果视频大小发生变化,则需要重新安装解码器和相关逻辑,否则可能出现解码屏幕或内存溢出。

硬编译解决方案的兼容性

当然,如果你使用Android的硬代码,你不可避免地会遇到一些比你爸爸的手机好一点的手机,而硬代码不会错的报告错误,但是你输出的图像非常不寻常。

Android很难解决兼容问题,代码小心,充分考虑机器类型的兼容性,不记下任何参数,其余可以做在白名单/黑名单上。

11不正确的图像大小和推力端的格式化处理

图像的格式和大小是非常重要的参数,它必须严格地配置正确。

比如：如果采集到的视频是 NV21 ，编码器只支持 I420，那么编码出来的图像自然会出现颜色问题。

比如：在一些场景切换的过程中，前后摄像头切换，视频的尺寸可能发生了变化，但是剪裁、处理、编码模块没有相应的修改尺寸，那么，也会出现各种视频错乱的现象。

六 播放闪屏

从根本角度来看,闪光屏幕的问题是,在播放过程中,两个不同的屏幕似乎被开往前开,所以闪光屏幕看起来像,例如,两个黑白的交互渲染图像。

1玩家缓冲机制的原因

网络不好的时候，播放器会频繁缓冲，曾遇到过一种案例，这是一个现场应用,在缓冲的时候，使用广告图片,在某些极弱的网络中,由于频繁缓冲，使真实播放屏幕和广告图像迅速被重新切换,导致闪屏现象。

玩家的缓冲策略完全可以避免这一点,即在每个缓冲之后,你不接受一个帧后即时渲染,而是适当地缓冲一些数据,然后发送缓冲结束的讯息,从而创建一个频繁的 ms级缓冲开关的闪光屏幕。

2推流端的原因

推流端产生闪屏的流，往往发生在有画面合成的代码模块，比如：叠加水印、摄像头/图片切换推流、连麦合流等等。

必须记住屏幕的合成,无论如何,避免发生,有合成/没有合成两个屏幕的交互。

7.播放噪音、噪音和反馈

与视频相比,音频更灵敏,视频屏幕很吵, mozaiks几乎不能接受,而且当声音有任何缺陷时,耳朵特别容易感觉,而且很难忍受。

常见的音频问题现象如下:

电流、爆炸、噪音或噪音

声音很响,不清晰

一个能听到自己说话的声音

1 参数配置问题

声音特别敏感,它涉及许多参数配置,一旦配置不太匹配，这会使声音听起来非常奇怪(例如样品频率为32,00赫兹,播放器配置为800Hz或44100Hz,减慢或加速音频的效果很明显.

我们需要知道的是,获取和播放都需要为系统API和第三方库配置正确的参数,如采样率、带宽、音频频道数等。

2 代码层面的原因

常见的代码级问题包括以下:

• 音频 buffer 大小不匹配，一段 1024 bytes 的音频，放到了 2048 bytes 的数组，导致尾部有随机数

• 音频 resample 重采样的算法问题，导致采样出来的数据出了问题

•Android的ByteBuffer删除了阵列,不能直接使用。 array()方法需要使用.get()方法

• iOS系统,其他应用程序通过系统API改变了AudioSession抽样的配置

3 网络波动

视频是一个连续的帧为帧的图像,在播放过程中,如果你不能按时渲染,你会得到卡片效果;如果你丢失几个帧,你会得到快速传送的效果。

音频是流畅的,虽然它也分成单独的音频帧,但是如果你不能按时播放或连续丢失更多的音频帧,你会注意到声音被中断和中断,特别是在高损失率和不稳定的网络环境中,这种情况很容易发生。

4 回声消除

回声一般出现在同时有音频的采集和播放的场景，比如：连麦互动、混音返听等等，采集到的音频通过扬声器又播放出来了，同时又被采集了进去，从而产生了回声或者啸叫声。

在这种情况下,通常需要通过系统语音除去API或第三方语音除去库(例如speexdsp、webrtc等)进行处理。

注:许多Android设备的硬件自驱动器没有良好的反响效果。

5 混音越界

音频的 PCM 数据，通常用 short 数组来存放，当我们做一些多路音频的混音功能的时候，如果不注意处理 short 类型的大小越界，则往往带来爆音的问题。

八 拖动不准

现象:在播放过程中,在拖延进度栏后,实际播放位置与拖延时的位置非常不同。

由于实时生成和传输实时流,无法拖动,所以问题主要发生在实时流或本地文件的播放中。

1 基本概念

首先,我们需要理解玩家拖动的基本原理:

视频是由一系列图像帧组成的，每一个帧都有对应的时间戳。拖动，就是告诉播放一个时间戳，由它直接跳转到指定的这一帧开始播放。

拖动到的时间点 = （进度条的 progress / 进度条最大值 100 ）x 视频总时长

2 关键帧间隔太大

由于解码器必须从 I 帧开始解码，才不会出现花屏现象，因此，播放器通常会寻找离 seekTo 视频帧最近的一个关键帧，从该关键帧开始解码播放。

假设关键帧间隔(GOP)为3s,那么关键帧时间点如下:

0s, 3s, 6s, 9s

如果拖动到 4s 的位置，那么播放器就跳转到第 3s 的关键帧开始解码播放，因此，会产生一定的误差。

关键帧的间隔越大，那么这个误差也就越大。因此，为了更准确地支持拖动，建议不要把关键帧间隔设置得太大。

3 直播丢帧

丢帧的情况多发生在直播场景，由于主播端的网络抖动或者内存不足，导致不得不被迫丢掉一些视频帧，而为了保证客户端解码后不出现花屏，丢帧往往伴随着一整个 GOP 的丢弃。

当GOP丢失时,一些关键帧的间隔变得更大,导致不均匀的拖动。

为了避免这种情况,建议在推力端打开动态编码,并且当网络不正常时,积极减少编码并迅速在缓冲区发送累积的视频帧,从而减少帧丢失。

4 发热

导致机器功耗高，发热严重的根本因素，无外乎就是一点：CPU/GPU 占用率高，所以，我们首先要分析下，哪些因素会导致 CPU/GPU 占用率高。

5 数据量太大

直播主要由：视频采集 -> 视频处理（剪裁、美颜、滤镜） -> 编码 -> 推流 这些环节组成。

哪些因素决定这个过程的数据大小?

视频的尺寸（例如：1280 x 720 的图像，明显要比 320 x 240 的图像处理起来费劲）

视频的帧率（例如：每秒 30 帧，明显要比每秒 15 帧，处理起来费劲）

因此,适当地降低视频的大小和帧速率而不影响业务体验可以大大降低后续链接的CPU/GPU的负载,从而大大降低功率消耗。

6 大量的格式转换

不同的模块需要数据格式化,往往有差异，例如,来自Android相机的数据大多是NV21,编码器通常需要I420格式的数据;例如,由ffmpeg解码的视频通常是YUV格式。渲染显示经常需要RGB格式,等等。

我们想尽量减少不同格式的数据转换,或者尽可能使用GPU来处理一些复杂的格式转换,例如,使用OpenGL直接渲染YUV格式的数据,而不是用 CPU 做一次 YUV -> RGB 的转换，这是一个好选择。

7放大图像

前面文章有提到，非常不推荐把一个小尺寸的图片 -> 放大 -> 大尺寸图片，这样很容易出现马赛克。

事实上,这种设计不仅容易显示 mozaic,而且在图像放大过程中,因为它涉及复杂的插值操作,它也消耗了大量的CPU。

同理，图像的缩小或者剪裁，同样也会消耗一定的 CPU，只不过相比于图片放大要好点。

因此，最好的办法，就是小心选择摄像头的预览分辨率以及推流的尺寸，尽可能让两者保持一致，这样，才能最大化地节省 CPU 的消耗。

8 软编/软解

这就是为什么每个人都理解CPU是软/硬解决方案的主要处理器,硬/硬解决方案使用专门的硬件编码模块大大降低CPU的负载,而与此相反,节省大量功率。

你只需要小心所有类型的Android硬件兼容问题,对于一些豪华的设备,添加硬盘/硬盘黑名单是好的。

9 其他方面

当然,有许多导致高电耗的因素,这些因素没有在这里详细解释,如下:

脸部识别/美观/滤波器,消耗大量CPU/GPU

代码逻辑中的内存复制操作太多

后端线程经常使手机醒来访问网络或读写SDCard

应用程序的一些动画功能

原文链接： 直播常见问题原因汇总 - 资料 - 我爱音视频网 - 构建全国最权威的音视频技术交流分享论坛

本文福利，C++音频视频学习包技术视频内容包括(语音视频开发,面试问题,FFmpeg,webRTC,rtmp,hls,rtsp,ffplay,srs)↓↓↓↓↓↓ 请参阅下文文章的底部下载

XTw.com.Cn系统网专业应用软件下载教程，免费windows10系统,win11,办公软件,OA办公系统,OA软件,办公自动化软件,开源系统,移动办公软件等信息，解决一体化的办公方案。