基于微信的直播方式

微信直播目前用的比较多的是微信H5直播，小程序推出后又多了一个直播的方式，特别是低延迟直播。

微信H5

微信H5直播播放的就是HLS，譬如写一个HTML页面放一个video标签就可以看直播。

<video autoplay controls autobuffer type="application/vnd.apple.mpegurl"
    src="http://ossrs.net:8080/live/livestream.m3u8">
</video>
1
2
3
HLS的延迟当然是挺大的，不过有些直播对于延迟不是那么敏感，譬如演唱会或者电视节目之类的。

如果一个片是10秒，HLS的延迟级别是在30秒左右，具体参考SRS WIKI。如果降低切片为3秒，那是否能到10秒？不是这么回事，低延迟不能忽略端的因素，而所有的切片协议延迟都很高，具体参考SRS WIKI。如果改进HLS切片方式，譬如HLS+动态切片，会稍微改善延迟，但是还是达不到RTMP目前2秒左右延迟的级别。

如何降低直播的延迟？主要在于端，目前CDN和服务器以及编码器都可以做优化，唯独端并非考虑了低延迟。譬如HTTP-FLV协议，延迟也很低，隐含的意思是Flash对于HTTP-FLV也是支持低延迟的方式，或者说考虑了延迟因素，可以设置缓冲区和最大缓冲区，解码缓冲也很小。譬如移动端APP自己解码HTTP-FLV，也是可以控制这些因素的。

微信H5还有一个降低延迟的可能，就是MSE。

微信MSE

MSE(Media Source Extension)，具体可以参考SRS #722以及videojs-flow，还有bilibili flv.js。

简单来说，MSE就是H5的video对象，提供了appendBytes()接口，可以自己解析各种封装后，给这个js的函数。就很类似flash后面开放的NetStream的DataGeneration模式的接口。其实Apple的媒体框架也是这个思路，不巧Android的多媒体API也是这样。所以直接接收底层的媒体数据，譬如mp4或者flv，甚至直接送annexb进去，能让用户控制解析封装，运行时就不用费力限制各种封装了。从延迟上来看，用户能控制的部分又增加了。

MSE的延迟多大呢？由于MSE不是切片协议，所以没有切片协议引起的延迟（同步的延迟），如果通过websocket传输flv或者mp4，这样可以做到流式协议。是不是一切看起来是那么的美好？但是这里有两个坑：

Chrome必须以GOP为基础appendBytes，也就是延迟至少是GOP级别。当然GOP可以做到比较小，譬如2秒。
微信还没有支持MSE接口。。。。。。
看来希望还是在微信小程序上。

微信小程序

为什么微信小程序是可能做到低延迟的？因为微信小程序非常像flash那个运行时，为了性能或者统一平台的优化，自然可以控制video对象的延迟。虽然小程序目前的使用和H5一样，也是一个HTML标签，但是微信是需要解析程序代码的，如果说小程序性能比H5高，那这些代码的解释肯定是微信自己做的，完全有机会可以做到低延迟。

的确是有可能的，因此我就试了小程序的video支持到什么级别了。对于直播：

可以支持HLS的。当然这个不是很关心，延迟那么的大。
可以支持HTTP-MP4。一般MP4就是点播，那么有没有可能支持直播？
HTTP-MP4流，或者MP4直播，或FMP4(Fragmented MP4)，万能的流媒体圈子已经折腾过了。而且是大名鼎鼎的Microsoft提出来的Smooth Streaming，当然现在已经死了且埋了。但是还是要试试的，万一有机会呢？可以参考SRS #174

结果发现真的是支持FMP4，只不过只解析了第一个Framgnet，心中万马奔腾啊。

结论

微信低延迟直播还没有戏。不过相对老外在力推的DASH，低延迟直播还是微信支持MSE和FLV更有戏。如果说微信支持MSE和FLV和我中五百万彩票概率一样，那么让老外想明白为何我们要用FLV或RTMP就和火星撞地球的概率一样，谁更有戏那是不言自明的。
--------------------- 
作者：win_lin 
来源：CSDN 
原文：https://blog.csdn.net/win_lin/article/details/54410876?utm_source=copy 
版权声明：本文为博主原创文章，转载请附上博文链接！