所谓希望越大，失望越大。绿屏依旧存在，而且严重了很多，多次测试下来，它成了必现问题，虽然很失望，但是从偶发问题到必现问题也是一个很大的“进步”。
3.黎明之前最黑暗的时刻，问题终于毕现了，却没了有效的排查手段。
由于 TCP 粘包问题，Wireshark 并不能完全正确的解析出每一个 RTMP 包，没有一个高效的办法查看 RTC 转换的 RTMP 包。
在忘篱同学的帮助下，通过 SRS 的 srs_rtmp_dump, 将 RTMP 数据保存为了 FLV 文件，具体用法：
#编译 git checkout 3.0release && ./configure --osx --with-librtmp --with-research && make -j8 #保存flv ./objs/research/librtmp/srs_rtmp_dump -r rtmp://127.0.0.1:1935/live/livestream -o output.flv > t.log通过 FFmpeg 发布 FLV 文件，绿屏问题重现了，莫名的兴奋。
ffmpeg -re -i green.flv -c copy -flvflags no_metadata -f flv rtmp://localhost/live/livestream
虽然知道了 FLV 有问题，可是接下来对于 FLV 的分析却犯难了，首先 FLV 格式分析的结果并没有任何问题，用 FFmpeg 抽取出 FLV 中的 264，再发布时也正常。这个 FLV 文件用 FFplay 播放也是有错误信息的。
当你无计可施，看着代码发呆的时候，休息一下可能是个解决问题的好办法。上班的地铁上，终于有了头绪：mark bit、stap，组帧逻辑判断条件，导致了两帧放到了一个 FLV 的 frame 中，造成部分终端不兼容。最终测试通过，版本正常发布，感谢这个过程中每一位同学的支持与配合。
总结即使 IDR 帧，也可以很小，小到都填不满一个 UDP 包。
SPS、PPS 和很小的 IDR 可以打到一个 STAP 的 RTP 包。
纯 Padding 包一定认真对待，没有实际数据的枷锁，它们可以做一些灵活的应用。
多帧封装到一起，有兼容性问题。
“事出反常必有妖”，代码没有玄学。
认真考虑数据的准确性，优先排查两端的数据。
工具可以显著的提升效率。
福利SRS 的 srs_flv_parser 中增加了 h264 video frame 中每个 nalu 的信息打印，希望对大家以后填坑有所帮助，提前发布预览效果，看看绿屏妖的原形。
「视频云技术」你最值得关注的音视频技术公众号，每周推送来自阿里云一线的实践技术文章，在这里与音视频领域一流工程师交流切磋。