年底了，要汇总一下整个年度的一些基本情况，在做整理时又重新认识了一个bug。当时处理时候肝了一个晚上，加班到夜里11点才搞定，感觉挺有意思的，已经加入到自己的错题集了，今天和大家一起分享一下。
背景介绍
9月份时候，测试提报一个bug：app和设备视频通话，如果在外网上就无法正常显示画面了。
这个非常奇怪了，当时设备端小伙伴进行了第一轮分析，按照之前的“三段论”进行问题排查。。。。
啥？不知道啥是“三段论”。
“三段论”：是个人总记出来分析定位问题的一套快速方案，仅局限于涉及网络传输的音视频问题分析。我们整个链路分为：生产端或者发送端，传输端，消费端或者接收端。因此收到问题反馈之后，逐步排查每一段，进行初步分析。
- 如果是生产端或发送端的问题，则在发送端送数据之时抓包；
- 如果是消费端或接收端的问题，则在接收端收数据之时抓包；
- 如果是传输段问题，则通过PC或者更换设备验证；
言归正传，当时小伙伴分析是发送端异常导致的，通过抓包显示：设备没有发送视频包。不过小伙伴也反馈一个现象，局域网内可以正常视频通话。
这里需要说明一个背景：webrtc支持在发送fake video capture的内容，也就是说：如果发送端没有摄像头设备，可以发送一个特定文件内容。实际工作中可以用如下选项进行开启：
–use-file-for-fake-video-capture=”filename”
问题分析
本次问题产生就和这个文件有关系。小伙伴排查提交记录，以及log定位后发现该问题是最近替换的一个文件导致的。之后为了验证猜想，增加log，发现确实在读取文件的某一个阶段，直接调用stop流程，结束发送线程了。
第一步，我们怀疑是文件在设备端不兼容呢，所以我们通过ffplay以及PC端的potplayer，vlcplayer等工具播放该文件，都是正常播放；
第二步，我们用Android 版本的播放器进行播放，也是正常；
至少到此播放器可以正常播放，和文件关系没有那么大。但是我们又换回到原来文件，问题就解决了。所以还是和文件有关系，只是播放器都可以兼容这个文件，但是我们的代码发送流程不兼容。当时和研发小伙伴确认该文件是经过FFMPEG转码过来的视频文件，自己也尝试通过其他的网站，工具转码，发现转码后的文件确实都有这个问题。
我们用对比视频分析工具进行排查，果真发现一点异常，如下图所示：
新的文件在movi列表栏，有多个字段是空值。难道在读取视频数据大小时，如果是空值就调用stop操作了？
为此我们重新梳理流程，增加log，最终确认在读取视频文件中视频帧大小时，如果size为0，就调用stopread操作，不再读取和发送视频数据了，但是音频数据是正常的，所以相当于建立音频通话了。
解决方案
既然知道问题是怎样的，那就知道如何解决，最后修改一个“>”号为“≥”，该问题妥善解决，提交完代码已经11点05了，就准备撤了。
至于为何会出现转码后异常现象，当时正在做其他的事儿并没有深入研究，目前也还没有review FFMPEG代码，自己感觉应该是video和audio数据做同步，所以需要插入部分padding数据，这部分等“杨康”之后再找机会跟踪一下。
作者：我是一枚爱跑步的程序猿，维护公众号和知乎专栏《MediaStack》，有兴趣可以关注，一起学习音视频知识，时不时分享实战经验。
版权声明：本文内容转自互联网，本文观点仅代表作者本人。本站仅提供信息存储空间服务，所有权归原作者所有。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至1393616908@qq.com 举报，一经查实，本站将立刻删除。
