流媒体前生今世

直播从古老的RTSP到RTMP，HTTP渐进式下载，到HTTP流，到HLS和HDS，到DASH，到私有的websocket。

目前直播分发有几个特点：

（1）偏好flv，少用ts

flv标准11页，ts标准174页。标准文档十倍差异，代码实现起来十倍都不止。因此一般的公司都喜欢flv，pc时代都是flv的天下，什么flv流，flv切片;因为自己写代码支持ts比较麻烦，用ffmpeg的代码又太庞大。直到移动端粗现，现在直播只支持pc的少之又少了，使用flv作为基础结构的产品要么艰难转型，要么就掩耳盗铃说FLV很优雅，HLS太垃圾。

（2）rtmp和hls并存

rtmp一般用于pc-flash播放直播，而hls用于移动端播放。flash能播放hls吗?前年jwplayer就支持了，可惜是商业版不开源;去年有很多开源的as播放器支持hls。而直播系统，特别是cdn的直播，不会更新这么快，pc端还是rtmp系为主。这个特点是由于平台客户端支持的流决定的，并非最佳方案，也不是用户愿意这么干。

（3）实时流大多使用rtmp

实时流，延迟要求在5秒之内的流，大多使用rtmp协议。pc上可以直接播放，移动端就需要使用ffmpeg解码播放。有没有更好的分发方案?实际上http-flv比rtmp更合适，延迟一样，要求服务器支持，pc能直接播，移动端需要使用ffmpeg，还有个好处是能穿墙。为何cdn大多不支持http-flv直播?因为一般的web服务器支持不了，这是个流媒体问题。

（4）rtsp永远死不了

这是监控行业的协议，我们都有门户之见，"RTMP这个烂货怎么还在互联网上用呢?RTSP多么优美!"因此有监控行业背景的公司做互联网业务，都带着门户之见不得已将RTSP转RTMP，而且还要愤愤的说只不过是不用装个插件而已。

直播的本质特点，就是需要专门的服务器分发，至少需要直播源站切片HLS后分发。也就是直播需要专门的流媒体服务器，目前开源的流媒体，最古老的是RED5，后面是CRTMPD，风生水起的是NGINX-RTMP，目前最新出的是SRS。

为何RED5不能一统天下?RED5和FMS一样古老，先行者如果不能放掉自己的光环，迟迟不肯变革，就会被后来者超越。RED5性能是很差，但并非是因为使用了java的原因，这个看看wowza就知道了，商业服务器wowza虽然是个内存杀手，但是支持的并发一点都不含糊。RED5没有广泛商用的原因可能一直是一个先行者，祖先的角色。软件只有快速变化适应需求才能发展，和年纪没有关系。

那么CRTMPD怎样?牛逼!使用单进程单线程异步socket，这是和nginx同时代的产物。CRTMFPD是有不少铁杆粉丝的，以那个时代开始做直播业务的为主。CRTMDP生不逢时，遇到NGINX了，不少NGINX的粉丝是技术牛逼的人物，不然怎么能看懂void*****呢?除了社区的差异之外，CRTMPD没有支持HLS，倒是支持了RTSP，这就是典型的倒行逆施，互联网上支持RTSP，大约只有CRTMPD能想到了。

NGINX-RTMP风生水起有几个很重要的因素。首先2012年开始CDN业务开始快速增长，随之直播业务也需求暴涨，没有特别满意的流媒体服务器;其次，NGINX在HTTP领域绝对是霸主，大家对于NGINX系的熟悉程度很高，便于维护;再次，直播点播使用一套服务器，很有诱惑力，这可以算是"万金油"效应，很多套服务器搞得焦头烂额，肯定一套服务器能解决问题;最后，CDN是运维比技术牛逼的行业，运维的信心都是运行出来的，NGINX运行那么良好，那么NGINX-RTMP也肯定不错。

当初有个跨国老牌的流媒体公司，劝说不要使用RTMP了，因为半年时间RTMP就会死掉，DASH会替代所有的流媒体协议。现在2年过去了，RTMP和HLS除了更加爆炸性应用之外，我看死掉的是那些过于技术至上的公司。

如果用一句话说流媒体直播：实时性要求高的用 RTMP 或 HTTP-FLV ，其他都用HLS。