直播未来属于RTMP还是HTTP？

直播未来属于RTMP还是HTTP？

HTTP 传视频比 RTMP 实现起来简单？HTTP 延迟太高？

答：直播通讯未来是属于html5的。

1，协议使用份额

如今国内90%的面向大众的直播平台都是采用的rtmp和httpflv的混合，hls很少，而国外大部分采用的dash，少部分用hls和其他协议。

2，先简单的描述下这些协议

httpflv：这种直播传输实际上就是利用的flv文件的特点，只需要一个matedata和音视频各自header，后面的音视频数据就可以随意按照时间戳传输，当然视频得按照gop段来传输，这种直播数据实际上就是一个无限大的http传输的flv文件，视频地址类似：

http://mywebsite.com/live.flv，客户端利用flv特性，可以一边接受数据边解码播放。

rtmp：rtmp是adobe研发的开放协议，rtmp其实实质上也是传输的flv格式的数据，同样是flv tag，只不过rtmp在传输上封装了一层，比如rtmp不仅可以直播，也可以推流。rtmp的直播原理同样也是利用了flv文件的特性，只需要一些头信息，后面就可以随意传输音视频数据，达到边传输边播放。

hls：hls是苹果公司开发的协议，http轮询传输，该协议主要的数据格式是ts视频文件，大致就是将裸流h264和音频直播数据，切片封装成ts段，形成无数的ts小文件，客户端先请求一个m3u8文件，该文件内部会有一列ts文件的地址，客户端按照顺序依次播放ts，以此类推，hls地址类似：http://mywebsite.com/live.m3u8，hls在大部分的浏览器利用html5video是可以直接播放的。

dash：这个协议国内用的不多，http轮询传输，但是国外很多平台都在用，比如youtube直播，该协议是google公司研发的，和hls如出一辙，同样是将直播流数据切片，只不过不是ts文件，而是mp4或者3gp文件，又或者webm（vp8，vp9）文件，该协议同样和hls一样也是http传输，同样和hls主打的是“自适应动态码率”，大概意思就是当客户端网络不好的时候会无缝切换到低码率的路线。

3，各种协议延时及其原因

rtmp和httpflv：这两种协议大致数据一致，所以延时原因都是差不多的。按理说tcp流式传输直播因该都是延时极低的，为什么rtmp和httpflv还有延时呢？原因在h264上，rtmp和httpflv都是传输的flv tag，视频tag的数据平常就是h264数据，h264解码有个IBP，I是关键帧，是一帧完整的图像，必须要先有个I才能解码后面的BP，BP帧可以随便少，但是I帧不能少，所以I帧必须是在flv tag传输中第二个传输的（第一个是h264spspps），但是I帧在h264流里不是常有的，是隔一段才有个I帧，这个一段的间隔，俗称GOP，当编码时候GOP设置很短，当客户端连接上来，服务器会以最快速度找到流中最近I帧，从I帧开始发送直播数据，然而当GOP很长，I帧间隔很长，或者等待下一个I帧开始向新连接发送数据，或者在缓存里找最近的上一个I帧开始发送，这里就是rtmp和hls协议延时的关键了，在各大cdn平台，叫“rtmp秒开技术”，原理就是将推流数据二次解编码，设置很小的gop。总的来说，gop设置1s，在不考虑网络传输链路延时情况，数据延时最大就为1s，运气好刚好就是I帧就是0延时！

hls和dash：这两种协议延时原因大致都是差不多的，因为切片了，切成小端的文件，单独开始传输，这就是延时的关键了，当然可以设置切成小文件，越小延时越低。按理说dash切片要比hls稍微先进一点，所以延时上dash要比hls低，但是同样的，切片了，就注定延时。

4，关于解码播放的优劣势

首先，我想说flash真的要被淘汰了，rtmp和httpflv目前在网页上只能用flash或者插件的方式解码播放，而且flash在cpu和内存上都是占用很高。但是在客户端app上，不用网页播放，你可以不用担心这个问题。网页上播放，hls和dash的优势就体现出来了，可以用html5直接播放，当然理论上，dash的mp4的兼容性要比hls更好。而且hls和dash支持动态适应网络，无缝调节码率，这在网络波动很大的地方，这个功能不错，当然个人对于这个功能无所谓，我情愿线下看高清，也不线上看马赛克。

5，总结

对于各种面向用户的直播协议，我只讲了一部分的，当然还有更多，这里就不一一列举了。以后在浏览器上肯定是html5的市场，无论是hls也好dash也罢，或者新兴的很多websocket直播也好，技术反正是在不断更替的，或许有天，html5突然支持flv播放了呢？

我列一个表作为总结：