最近工作上碰到两个问题，都是播放时候出现花屏现象，因此汇总一下，方便后续防止踩坑。
问题一
第一个是设备播放特定文件时出现花屏现象。
碰见类似问题，一般会进行问题怀疑点预设，初步猜想可能发生的原因：
第一：文件问题本身问题：包括文件损坏、头信息损坏等；
第二：参数问题：包括视频参数、格式档位、帧率等；
第三：显示问题：yuv格式、surface相关内容。
所以逐步击破各个猜想，摸清问题产生的原因，完成问题修复。
1.1 文件排查
第一步确认该文件是否正常，确认不是格式导致的播放问题。
通过MediaInfo工具查看，以及atom工具，信息没问题，其中标注一下可能怀疑的点。
之后测试相同的文件，推到另一台设备中，用系统自带的播放器进行播放，显示正常。
1.2 格式排查
之后查看硬件厂商的官方datasheet中支持的视频编解码格式，应该是支持的：
http://opensource.rock-chips.com/images/4/49/Rockchip_RK3288_Datasheet_V2.7-20191227.pdfopensource.rock-chips.com
1.3 播放器排查
另一方面，采用其他的播放器（万能播放器，内核是IJKMEDIA）播放该文件，确认播放器是否有问题：
采用系统自带播放器播放其他的MP4文件，显示正常
看到这里是不是觉很有意思了？继续盘它。
1.4 log分析
我们发现异常时（不管是默认播放器和万能播放器），log都是显示如下内容：
之后又下载了VLC for Android和其他的播放器，显示硬解时，会有崩溃信息：
好像看到一个异常，至少现在有线索了。
1.5 解码排查
之后用VLC for Android将硬件加速关闭后，播放正常了（这时候发现VLC功能强大，这个也是一直再找的一个功能，可以用户自己决定是否关闭硬件编解码、是否只用软件解码，只是为了验证功能）
哇咔咔，见证奇迹的时候出现了，竟然播放正常了，所以软解时候是正常的。
综上，可以判断应该是硬件厂商的某一个库异常导致硬解有问题了
1.6 硬件排查
通过恢复出厂、刷机都不能恢复正常播放、相同版本换一台机器就正常了，所以更加明确定位该问题和硬件或者硬解库有关系。
之后硬件童鞋帮助更换CPU、主板逐个模块确认，原来是主板上解码模块异常了，更换后正常了，最终问题得到解决。
总结：
碰到类似花屏问题：首先怀疑是解码异常、逐步排查收发数据是否正常（通过抓包可以查看）、解码（导出解码数据）、显示（送surface前导出）、以及通过其他的播放器确认软解、硬解是否正常等手段排查。
问题二
我们APP在客户现场出现视频不完整、花屏等问题，而且是必现的，这个现象非常严重了。
这个任务紧急、重要，必须短时间内解决，一次抽调精干大佬，一起攻克。
2.1 收集信息
最初介入时，研发大佬以及有了初步问题分析：
-
客户到两台欧洲云服务器，速度在5~8 MBit；
-
国内到欧洲云的速率，在50Mbps；
-
客户到欧洲云的实际丢包情况比较严峻，基本每秒必定丢包，没有不丢包的，这种简单的ARQ机制救不回来这么多数据；
-
非常多的ARQ容易导致网络风波
碰见该类类似问题，初步猜想可能发生的原因：
第一：传输端问题：包括传输端端口异常、数据采集异常、编码异常等；
第二：网络链路问题：包括网络带宽、网络状态、网络协议等；
第三：流媒体服务器问题：包括服务器处理能力、服务器转发转码异常、服务器端口异常等；
第四：接收端问题：包括APP自身问题、手机WIFI异常、手机解码异常、手机显示异常等内容。
2.2 抓包排查
首先客户有提供了一个抓包，然后查看发现，有非常多的丢包，而且做了ARQ重传请求：
正常情况下，做了这么多ARQ请求后，会显示完整视频出来才对，然而现场看现象越来越差，帧完全丢掉了。
2.3 链路排查
通过Iperf工具查看，当前tcp链路和udp链路带宽如下：
TCP链路状态：
UDP链路状态：
可以看出，客户现场带宽还是比较低的，这中网络条件是各种弱网对抗手段启动的前提条件，虽然后一定风险使得网络变差，但是还是会触发的。
2.4 APP端排查
为了更精确定位问题，重新查看抓包，发现所有的ARQ请求都是在云端和设备端发起的，为了验证该猜想，排查APP端的问题，重新抓取了APP端的抓包，显示将近APP端10+s的播放，APP仅仅只有两次ARQ请求，说明APP端的网络状态还不错，偶有丢包而已：
2.5 架构摸查
因为我们的架构是这样的，APP端服务器、服务器到被叫端是独立的。这样基本上是流媒体服务器架构的基本类型，让呼叫和被叫端分别相应自己的网络状态。不过对于实时通话影响会比较严重，也是我们之后要改进的地方。
所以进一步排查服务端的相关协议，发现如下现象：
因此导致被叫端和服务器之间网络拥塞了，导致即可app端信号非常好，也无济于事。
因此服务端的童鞋协助排查了该问题：ARQ的灵敏度做测试时被调整了，导致部署时短时间内发起比较多的ARQ请求，造成呼叫异常。将此次调整的参数回退后正常了。
虽然是服务端的童鞋的问题，出现不该有的错误。但是这个排查过程，以及客户现场的第一手网络链路数据资料的收集，仍然有很多可取之处，防止之后类似现象的发生。
总结：
呼叫流程中花屏问题需要分不同阶段，二分法逐步确定该问题发送的阶段，比如发送端、网络端、接收模块、解码模块、显示模块、不同的模块分析问题的方式是不一样，借用的工具也不一样，善于利用工具验证自己的猜想，更快的解决问题。
如果能读到这里，都是深度钻研的技术爱好者，想请您帮个忙：
如果内容对您有帮助，请您花一秒中时间点赞、关注；
如果觉得能够帮助他人，欢迎转发、转载；
您的支持是鄙人前进的动力，感谢您的持续关注。
