怎么做到微信直播，HTML5直播，低延时

目前手页直播，主要方案有如下几种：

1,基于hls切片直播，前前是应用的主流,服务器可以选fms,wowza,nginx,srs之类

优点：集成方便，支持度高，兼容性好，主流手都支持，是目前直播技术主流。

缺点：延时大，一般服务器可以控制切片时长（延时可以控制在15-30秒之间）

2,基于浏览器mse技术，目前端技术上有B站的flv解码器。后端技术srs之类。

优点：集成方便，兼容性一般，原有技术平台可以保留，延时可以控制在10秒内

缺点：（主要是部分浏览器不支持mse,），目前iOS微信内不支持，延时稍大。

注：有人用h264的解码，代替flv,效过接近。

3，基于webrtc技术，目前只有wowza支持。

优点：延时少

缺点：兼容性差，目前ios不支持，原技术方案要调整，项目改造大。

4，基于ovmeet技术自建流服务直播，

优点：延时少，超低，可控在1秒内（测试在0.2秒左右），兼容好，所有html5手机平台通吃，技术兼容原平台推流rtmp,rtsp,rtp。

缺点：要自建流服务，

HLS (HTTP Live Streaming)

Apple的动态码率自适应技术。主要用于PC和Apple终端的音视频服务。包括一个m3u(8)的索引文件，TS媒体分片文件和key加密串文件。

常用的流媒体协议主要有 HTTP 渐进下载和基于 RTSP/RTP 的实时流媒体协议，这二种基本是完全不同的东西，目前比较方便又好用的是用 HTTP 渐进下载方法。在这个中 apple 公司的 HTTP Live Streaming 是这个方面的代表。它最初是苹果公司针对iPhone、iPod、iTouch和iPad等移动设备而开发的流.现在见到在桌面也有很多应用了，HTML5 是直接支持这个。

但是HLS协议的小切片方式会生成大量的文件，存储或处理这些文件会造成大量资源浪费。如果要实现数天的时移，索引量将会是个巨额数字，并明显影响请求速度。因此，HLS协议对存储I/O要求相当苛刻。对此，也有公司提出了非常好的解决方案。

新型点播服务器系统，独创了内存缓存数据实时切片技术，颠覆了这种传统实现方法，从根本上解决了大量切片的碎片问题，使得单台服务器的切片与打包能力不再是瓶颈。其基本原理如下：

不将TS切片文件存到磁盘，而是存在内存当中，这种技术使得服务器的磁盘上面不再会有“数以吨计”的文件碎片，极大减少了磁盘的I/O次数，延长了服务器磁盘的使用寿命，极大提高了服务器运行的稳定性。同时，由于使用这种技术，使得终端请求数据时直接从服务器的内存中获取，极大提高了对终端数据请求的反应速度，优化了视频观看体验。

RTSP协议，这应该是实时性最好的了，如果要想实时性要求很高，比如0.5s以内，这个是不错的选择。前阵子模仿spydroid写了个建议的rtsp 服务器，其实就是options，describe，setup，play，pause，teardown这几步了，这个协议用的最广泛，网上介绍也比较 多。要想真正深入了解rtsp协议，c++语言功底好的可以查看live555 。

RTMP协议，自己最近研究的，如果有兴趣，可以看看我的其他文章。

JW Player在HTML5模式下播放M3U8文件方法：

jwplayer("mediaplayer").setup({

playlist: [{

sources: [{

file: 'rtmp://' + path + '/' + name

},{

file: 'http://' + path + '/' + name // 这里可以写m3u8的url。

}]

}],

height: 360,

primary: "flash",

width: 640

})

---