牵着老婆满街逛

严以律己,宽以待人. 三思而后行.
GMail/GTalk: yanglinbo#google.com;
MSN/Email: tx7do#yahoo.com.cn;
QQ: 3 0 3 3 9 6 9 2 0 .

深入浅出看流媒体前世今生,分分钟二逼变牛逼

转载自:http://tech.lmtw.com/technews/201504/115637.html

  【流媒体网】消息:CDN这几年爆炸式增长,带宽提速是根源,而HTTP始终还是那个屌样,因此目前CDN大多是资本性行业,不用多少知识就能干了;直到流媒体粗现,直播咋这么难搞呢?因为它是流媒体,让我带你深入浅出看流媒体前世今生,分分钟二逼变牛逼。

 

  流媒体分为点播和直播,点播已经堕落为HTTP文件了,直播永远不可能只用HTTP就OK,这是他们的业务差异导致的。流媒体本质上是:现实的图像,经过编码器压缩,持久化为点播文件或者直播流,经过传输,在终端解码和展示。

  点播为何属于HTTP而不是流媒体呢?点播,譬如电影或者录制的影像,传输给观看的终端时是不变的,一万个人看一个电影无论什么时候看都是一样的媒体数据,因此传输上直接使用HTTP就可以了。点播的流媒体特征还是有的:

  点播的重新编码,譬如为不同终端输出不同码率和尺寸的点播文件,需要媒体知识了。这部分因为使用太广泛,所以开源届早就支持得很成熟,ffmpeg对文件重新编码已经做得很好了。

  点播P2P,这个实际上分为客户端的P2P和web P2P,这个和媒体没有什么关系,但属于点播需要做的范围,没有现成的方案。(插播广告:观止创想已经支持了点播HLS的P2P,现有系统不用修改就可以加上web P2P)

  其他的什么分片,DRM,弹幕,分享,多终端转封装,文件调度,HTTP API调度,热点,mp4/flv-range请求,存储等等。大多都有了成熟的方案,和HTTP文件一样的技术,要么就是播放器支持,这些和流媒体一毛钱关系都没有。

  这就是为何CDN支持点播支持得很得心应手,几乎所有的CDN都能直接支持点播分发,甚至一些新兴的行业公司,譬如在线教育,对于点播都能自己搞。点播就是HTTP而已,不属于流媒体范畴。

  直播呢,从古老的RTSP到RTMP,HTTP渐进式下载,到HTTP流,到HLS和HDS,到DASH,到私有的websocket。这些不过是直播分发的表象,譬如HTTP直播流就是HTTP点播吗?不是。HTTP点播本质上是文件分发,而HTTP流是流媒体服务器在内存中将直播的包,打包成RTSP、RTMP、HTTP后发送给每个客户端。

  当然总有例外的,有一个公司尝试过直播进行点播化,就是时移直播,将直播流录制成点播文件,然后客户端请求时总是请求点播。这种私有协议迟早是要死掉的,只有自己的播放器能播,而且得在CDN上部署自己的流媒体;现在这个公司也放弃了自己的“高大上”的私有协议——互联网的基本精神就是开放标准。可惜中国人很难认同这个理念,牛逼的总喜欢搞私有协议,譬如使用websocket的公司,大多属于这种类型,牛逼的人太多就是这种结果,一般这种公司也很有钱,譬如某上市的做在线秀场的公司。

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

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

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

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

  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也肯定不错。

  SRS粗来了,并非石头缝里蹦粗来个SRS,SRS其实诞生的历史是:第一个版本实际上是参考NGINX,基本上和NGINX-RTMP同时间点做出来;第二版本是改用ST作为基础结构,支持RTMP直播点播;第三版本是从CDN出来后重写的,只支持直播。为何SRS不使用NGINX那种基础结构,这个和google为何开发golang的原因一样。SRS和NGINX-RTMP最重要的区别有两点:其一,使用类似golang的服务器架构;其二,流媒体业务驱动的产品管理,如果可以装装逼,SRS是以流媒体业务为主的服务器,而不是以分发协议为主的服务器。

  什么是以流媒体为主?流媒体系统的层次包括:网络层(socket或st)负责传输,协议层(rtmp或http)负责网络打包,封装层(flv、ts、hls、hds、adts、annexb)负责编解码数据的封装,编码层(h.264和aac)负责图像压缩。流媒体服务器的重点在于封装层,譬如flv、ts、hls、hds、adts和annexb的解析和打包都是自己实现的代码,参考标准规范,支持完善的封装转换和解析。而网络层因为使用st简化,使得协议层更简单,错误的概率更低,这个和流媒体的关系就不大了。

  什么是以业务为主?“跑起来”和“商用”是两回事情,商用需要对于流媒体的业务有很好的支持:譬如vhost,这个是计费才有的概念,基于app的也能计费,结果就是要求用户不能app重复,新增app需要联系运维,凡是添加app需要联系运维的cdn,肯定是NGINX-RTMP;譬如日志,出现问题能将流媒体的整个链条的日志都能找出来,从边缘到回源链接,到上层节点的日志,一直追溯到推流连接的日志,每个日志都是基于连接的;譬如rtmp+http-flv+hls,国内主要的直播业务都能支持,还有hds可以供那些想装逼的客户用;更多牛逼的业务功能就不啰嗦了。

  对于流媒体服务器,除非能忘记HTTP服务器,才能看清楚到底为何流媒体和HTTP没有一毛钱关系,而流媒体在于团队对于流媒体和服务器的理解,而并非找到一个万金油服务器能涂抹掉客户问题。

  直播这么多协议,这多么服务器,当前直播重心在哪里?该如何选择合适的协议?只要问自己三个问题就可以了:

  延迟要求,是否要求低于5秒的延迟?如果是硬指标,就只能选择RTMP或HTTP-FLV流。移动端需要自己编译FFMPEG支持,无法直接播放。

  终端适配,是否要求支持PC和移动端(IOS和Android)?如果需要广泛支持移动端,HLS是最好的选择。

  节约带宽,是否要求支持WebP2P?如果需要支持FlashP2P,或者移动端P2P,选择HLS。

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

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

  协议请参考:https://github.com/winlinvip/simple-rtmp-server/wiki/v2_CN_DeliveryHLS

  服务器请参考:https://github.com/winlinvip/simple-rtmp-server/wiki/v1_CN_Compare

  关于SRS的架构参考:https://github.com/winlinvip/simple-rtmp-server/wiki/v1_CN_Architecture

posted on 2016-05-11 17:01 杨粼波 阅读(643) 评论(0)  编辑 收藏 引用


只有注册用户登录后才能发表评论。
【推荐】超50万行VC++源码: 大型组态工控、电力仿真CAD与GIS源码库
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理