问题背景：
最近开发了一个HLS服务，主要是满足用户在浏览器上播放直播和点播视频的需求，特别像小程序或者微信这种，只有有链接就能查看视频，也不用装APP，还是方便不少。在开发过程中排查了一次花屏问题，感觉比较典型，分享下排查思路，其实这种问题排查思路在前文讲过，这篇就是对这篇文章中提出思路的实践。
问题现象：
HLS服务上线后，用VLC或者浏览器播放视频时，总是在首屏出现局部花屏或者马赛克现象，虽然后面偶尔也会出现一下，但是概率远远没有首屏这么高。首屏出现不仅仅影响了首屏速度，影响体验也不好，用户刚打开链接就看到花屏，也有点说不过去。
当时时间比较紧张，就是将一个切片丢掉，然后从第二个开始播放。虽然花屏绿屏问题消失了，但是首屏速度影响非常大，所以还是要彻底解决，不能使用这个临时规避方案。
分析思路：
为了让大家看清排查过程，画个简单示意图，说明下码流的传输过程：
注：
1. 设备侧主要是就是推流端，各种摄像头IPC、国标平台、NVR等能产生码流的软硬件设备和服务器，码流格式的RTP PS H.264俗称国标流；
2. 公有云就是开发平台上的各种流媒体服务器，其中GB接入服务器通过标准协议对接软硬件设备，将国标流转成我们公司私有流，流媒体服务器做私有流分发，HLS服务支持客户端浏览器HLS协议拉流，同时将私有Raw流转成TS流；
3. 用户侧凡是支持HLS协议的浏览器或者小程序都可以使用正确的URL来进行拉流观看视频。
既然码流在用户侧的浏览器播放存在花屏问题，那么通过上面示意图我们将设备上来的码流各个传输阶段写成码流文件进行分析，如果在哪一步出现问题，则将问题定位在具体的码流处理模块中，再结合代码分析出码流到底在哪一步出现了问题。
排查步骤：
下面我在各个模块增加了写文件调试功能，将码流每个过程中生成的文件写下来，用分析工具进行播放和分析。我们摄像机设备端配置的帧率是25，I帧间隔是50，那就意味着2s一个GOP。实际TS切片时，也是以GOP为单元进行切片，一个TS文件大小在两个GOP左右，既然首屏的第一个TS文件出现大概率花屏问题，那就先分析前两个GOP的帧情况：
步骤1：
既然HLS服务返回给客户端播放的视频出现了花屏和绿屏，那先分析生成的第一个TS文件码流是否正常：
发现逐帧播放时，从第5帧开始出现花屏，同时发现TS里面的PTS时间从13500增加到36000，实际每个增加正常情况是3600左右，基本初步判断有视频帧丢掉导致，因为P帧的播放可能要参考前面的I帧和P帧，假设参考帧丢掉，后面P帧播放就会出现花屏，同时再用StreamEye工具分析这个TS的确如此：
工具分析发现每个GOP里面只有43帧，和设备端配置的50帧一个GOP缺少7帧，下面就继续在分析GOP里面为50时出现在那个模块，这样将问题缩小化；
步骤2：
PS流是国标接入服务器收到码流后，除去RTP头后些下来的文件，用专业软件逐帧播放和Elecard StreamEye分析：
通过分析发现前两个GOP文件播放都是正常的，那说明设备送上来的国标流是没有啥大问题的
步骤3：
PS流后面就是国标接入服务器转化成我们内部的私有流，分析同样也是正常的，因为这块已经把H264文件提取出来了，分析后发现都是可以正常播放的。
步骤4：
既然国标接入服务器收流和转封装私有流都正常，但是HLS拉流切片出来的第一个TS切片缺少了几帧，那么问题肯定出现在国标接入服务器以上到HLSTS拉流服务器之间。
步骤5：
通过流媒体分发服务器同学定位，说自己收到国标接入服务器的第一个GOP就是43帧，而且几乎必现，后面通过回溯国标接入网关向流媒体分发服务器推流这块的代码发现内部在推流过程中做了是否有音频的判断，其中这块判断逻辑影响了前几帧视频的发送，最终调整这块处理逻辑问题得到解决。
结论：
这种因为网络或者音视频数据本身导致的花屏、绿屏问题，排查起来基本思路就是分阶段排查，摸清码流的传输路径，在关键地方写文件或者打日志，通过专业音视频分析工具，把问题定位到模块内部或者模块之间的边界上。模块内部一般分析代码对码流的具体处理，模块之间通过抓包把问题因为传输导致的原因排除掉，通过以上定位问题思路就能分析出视频播放的各种疑难杂症。
