1 直播中为什么会出现花屏、黑屏、闪屏?
主播没有打开摄像头权限,推流端没有做好权限校验处理。
采集Camera数据,就要开始编码,如果编码失败,没有推送数据,那就会黑屏。
拉流端遇到不支持的视频格式,或者解析出来的数据异常,出现解码失败,导致无法播放视频,出现黑屏。
推流过程中由于网络问题不得不丢帧处理,此时丢失了参考帧,导致后续拉流段解码的时候因为失去参考帧解码出来的数据出现花屏情况。如果需要丢帧,应该一次就丢掉整个GOP的数据,不然就可能出现花屏现象。
播放器拉流的时候首帧不是关键帧,导致花屏,一定要判断首帧是关键帧才开始处理,不然没有关键帧整个GOP的数据解出来都有问题的。
推流端直播size发生变化,拉流端没有重置解码器,导致拉流端解出来的数据异常。
硬解码的兼容性问题,出现编码器无法支持格式,例如相机采集的是NV21,但是编码器只能支持I420,那推出去的视频就会出现色差。
2 音视频软件性能优化
稳定性优化
-
内存处理:
编码过程中养成良好的习惯,malloc和free对应,new和delete对应。释放内存之后,一定要将对应的指针置空,不然会出现野指针问题。
内存检测工具:asan和memory leaker,功能做完了,记得用这个工具跑一下。
防止内存抖动,频繁的内存抖动暴露了程序中内存申请的不合理,也会拖慢整体的运行效率。
-
ANR处理:
pthread_join卡死问题,音视频中经常出现此类问题,释放资源时,子线程卡死了,pthread_join一直卡在那儿,导致主线程ANR。线程设计的时候要特别注意。
主线程一定要谨慎操作,不能做网络请求、IO操作(一些IO操作比较隐蔽,例如解析视频)等。
线程优化:
线程设计,是否一定需要这个线程,能不增加就不增加,增加一个线程要申请一定的资源,而且还会有多线程的问题。
C++ Handler Message消息机制。
多线程安全。
pthread_join卡死问题,上面提到过。
功耗优化
数据量太大,音视频处理的视频帧现在一般都1080P的,相对比较大。
操作比较多,YUV2RGB的转换比较频繁,如果是GPU的处理还好一点,CPU计算转换则很耗资源。
软编码和软解码消耗大量的CPU资源。
音视频处理中会应用特效、美颜、算法等处理,这些都比较耗资源。
音视频中大量的memory copy操作,也会消耗资源。
3 音视频技术中的卡顿优化
我们还是以直播为例,拉流端有时候会出现卡顿,我们需要从全链路的角度分析这些卡顿。
-
音视频不同步:
- 推流端音视频同步没做好,那这种卡顿很危险,会一直持续下去的,而且无法纠正。RTMP推流的时候需要好好分析时间戳的问题,A-V不能相差超过100ms
推流端在弱网丢帧的情况下也要做好音视频同步,一般要丢帧整个GOP,这时候也要相应丢掉对应时间点的音频数据。
拉流端缓冲设计要做好,解码队列中数据不够导致音视频解码时同步总是对不上。
点播情况下有些视频很怪:视频中封装的音频和视频相差比较大,有时候会相差好几秒,这就是这个视频源有问题了。
-
弱网环境:
弱网情况下,推流端没有适配好的丢帧策略或者说适配了丢帧策略,但是在弱网情况下还是推流较高清的视频,在拉流端播放会出现卡顿。
拉流端没有缓存一段数据,一遇到网络抖动,会出现卡顿。
-
处理耗时:
推流端处理纹理时比较耗时,加了滤镜、美颜、其他算法处理导致采集比较慢,会出现掉帧卡顿。
CDN分发不行,请求负载过大,导致CDN分发出现异常。
4 直播关键技术指标
推流平均码率
丢帧率
自动切换码率频率