最近在搞音视频推流时，发现微信小程序端“偷偷更新”后，拉流时出现了加载失败的问题。
小程序端一直在拉流之后一直在报2004，就是开始拉流但是一直失败。
然后官方文档和论坛就再也找不到任何相关信息了
同样，ffplay播放完全没有问题。那么又是同样的步骤——面向猜测开发
猜测
先试验下，ffmpeg进行推流，小程序播放正常。
于是使用flvdebugger进行分析，发现两者的metadata的存在差别。
下图是我推的流，这里我们没有在matedata中显式设置音频码率
于是又出现了一个大胆的猜想:
小程序liveplayer音频播放在某些情况下依赖于matadata中的音频码率，原来客户端推流音频码率设置为0，触发liveplayer的bug无法播放
至于微信为啥要这么做，可能的情况是：
- 为了确保直播中的音频质量，liveplayer设置了最低的播放码率要求。
如果检测到当前音频流的码率低于指定的阈值，那么播放器认为这个流存在丢包，导致卡顿等风险。
为了用户能够听到高质量的音频，干脆就不让他播放了，等到码率恢复再执行。
- 也有可能单纯没有考虑音频码率为0 的边界情况，导致bug
但是出于某种原因，微信没有根据实时的流计算码率，而是依赖于不稳定的metadata中设置的码率，导致播放出现问题
验证解决
既然只是需要一个pts，那么完全可以再静音期间推送空的音频帧，已确保音频的pts连续
那么播放器的画面就应该不会卡顿
那么解决方式就是在metadata中添加音频码率
不过音频码率没有办法精确计算，所以可以参照2019-10-22-音频码率估算 - huangtengxiao 进行估算
基本设置在100-150kb/s都可以，（“反正小程序好像也没有怎么用它”）
设置之后再推流，播放完全正常
参考文档：
本文会经常更新，请阅读原文： https://xinyuehtx.github.io/post/%E5%BE%AE%E4%BF%A1%E5%B0%8F%E7%A8%8B%E5%BA%8F%E9%9F%B3%E9%A2%91%E6%B5%81%E5%8A%A0%E8%BD%BD%E5%A4%B1%E8%B4%A5%E9%97%AE%E9%A2%98.html ，以避免陈旧错误知识的误导，同时有更好的阅读体验。
本作品采用
知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议
进行许可。欢迎转载、使用、重新发布，但务必保留文章署名黄腾霄（包含链接：
https://xinyuehtx.github.io
），不得用于商业目的，基于本文修改后的作品务必以相同的许可发布。如有任何疑问，请
与我联系
。