随便写写的，手机推流问题。

上次跟一个朋友微信，说到一些手机推流H5无法播放的问题。感觉微信是发布清楚的，于是答应写篇文章。太懒了，于是拖了好几天。随便写了，问题入手吧还是。

1，为什么部分手机推流无法正常播放？

首先要搞清，H5播放器没那么玄乎，无非是把flv格式转成mp4塞到浏览器里。可以理解成 flv = h264 + aac mp4= h264+aac。这个问题出现在h264里。所以单纯改h5播放器内核无法解决。

2，和软解硬解有关系么？

然而并没什么卵关系。HTML5标准下，为了增强网页渲染，你所看到的东西，包括网页都是硬解(GPU渲染)出来的。强行关闭硬解码，改用软解码（CPU渲染）只会增大开销。

3，那为什么会产生这个问题？

这必须要从浏览器如何解析视频开始说起，首先video标签支持，其实是浏览器内核打进了h264 的codec来解析视频。然而市面上h264编码器 和 解码器都有很多种，不一定完全匹配。如果编码器编出来的东西，某些特征不能支持就会造成浏览器根本解不出来。

4，这个问题有办法解决吗？

必须有，分为播放器端解决，和服务端解决两种解决方式。

5, 如何在播放器端解决，有什么优缺点？

播放器端解决基本是依托于wasm技术，将C++编写的codec编译成汇编，也就是说，播放器要自带codec而不是用浏览器的。

优点是如果自建的codec写的很好，兼容性很高，而且可以顺便解决掉某些系统下（Linux的一些系统）本身没有codec的大问题，不用用户安装。

缺点是，会大幅增加播放器体积，影响加载拖慢首屏时间。（要知道，优化首屏时间，我都是拿秒表计时的。）以及 chrome58以下版本根本不支持wasm。另外，找一个能写codec的C++程序员不便宜，成本相当高，所以比较少用。

6，如何在服务端解决，有什么优缺点？

服务端无非就是转一次码。

优点是 不需要客户端做任何改进。

缺点是，首先转码对服务器有消耗，增大延迟。第二，任何形式的重新编码，都有可能在码率相同的情况下降低画质 （这也就是B站UP主，尤其是视频后期，压制必须自己做好，避免二次压制的根本原因）

7，还有没有别的解决方案？

找浏览器的开发者怼，让他们升级codec。。这个。。相当慢。

8，什么样的手机会出这个问题？

和移动端推流框架关系较大。手机端推流框架，和内嵌codec谨慎选择比较好。手机主播端发布之前，需要和H5、Flash端，移动播放端进行联调（对，还存在同一束流iPhone 或者安卓播不了的情况）

9，出了手机推流还会出现这种情况么？

会，编码器推流也会的。而且和上述情况一样，可能是h5、flash、移动端任何一个播不了。事先必须做好联调。

10，如何向用户解释？

虽然天天被问起，但并么有办法解释。直接告诉他们会想办法解决，并转移话题。反正也不是一个写JS的人能搞定的事儿。呵呵。。。