HLS与RTMP ,RTSP对比

来源:互联网 发布:淘宝自定义分类模板 编辑:程序博客网 时间:2024/06/05 03:16
你说的应该是 HTTP Live Streaming [1] 吧。这个是 Apple 为了提高流播效率开发的技术,特点是将流媒体切分为若干 TS 片段(比如每10秒一段),然后通过一个扩展的 m3u 列表文件将这些 TS 片段集中起来供客户端播放器接收。

这样做相比使用 RTSP 协议的好处在于,一旦切分完成,之后的分发过程完全不需要额外使用任何专门软件,普通的网络服务器即可,大大降低了 CDN 边缘服务器的配置要求,可以使用任何现成的 CDN。分发使用的协议是最常见 HTTP,代理服务器对这个协议的缓存优化相当成熟,而很少有代理服务器对 RTSP 的进行缓存优化。这对播放(软)实时视频有相当大的优势,因为这样分发后,对源服务器的负载压力小得多。

对于非实时视频,同样的好处也是存在的:如果你要在一段长达一小时的视频中跳转,如果使用单个 MP4 格式的视频文件,并且也是用 HTTP 协议,那么需要代理服务器支持 HTTP range request 以获取大文件中的一部分。不是所有的代理服务器都对此有良好的支持。而 HTTP Live Streaming 则只需要根据列表文件中的时间轴找出对应的 TS 片段下载即可,不需要 range request,对代理服务器的要求小很多。所有代理服务器都支持小文件的高效缓存。

此外,HTTP Live Streaming 还有一个巨大优势:自适应码率流播(adaptive streaming)。效果就是客户端会根据网络状况自动选择不同码率的视频流,条件允许的情况下使用高码率,网络繁忙的时候使用低码率,并且自动在二者间随意切换。这对移动设备网络状况不稳定的情况下保障流畅播放非常有帮助。实现方法是服务器端提供多码率视频流,并且在列表文件中注明,播放器根据播放进度和下载速度自动调整。

至于为什么要用 TS 而不是 MP4,这是因为两个 TS 片段可以无缝拼接,播放器能连续播放,而 MP4 文件由于编码方式的原因,两段 MP4 不能无缝拼接,播放器连续播放两个 MP4 文件会出现破音和画面间断,影响用户体验。

前两年我尝试过一个基于 HTML5 < audio > 标签 + CBR MP3 格式 + Icecast 流媒体服务器的网络广播台的网页应用(预想是给 apple4.us 做 Livecast 的,就是听众只需要访问一个网页就能够几乎实时听到访谈节目),采用的正是 HTTP Live Streaming 的思路。通过对 MP3 音频流进行帧切分,基本能做到连续播放。唯一问题是浏览器不支持 TS 格式, < audio > 标签在两段 MP3 之前切换时会破音。这样只能对谈话类内容适用,如果播放连续的音乐有时候会听出破绽。

iOS 设备上启用 HTTP Live Streaming 非常简单,也是苹果官方推荐的方式。Adobe 的 Flash 流媒体服务器的新版本也要支持这个技术的 [2]。这样普及开来是好事,用户体验更好、网络压


[1]: en.wikipedia.org/wiki/H
[2]: arstechnica.com/apple/n
2011-05-24 13 条评论    

trueice,trueice

4 票,来自 Beo、知乎用户、JasonChang 更多
mp4比较土,不是流式文件,必须有索引才能任意seek,因此adobe和微软纷纷支持基于f4v afra box和ismv (fragmented mp4)的http streaming,可惜apple不支持。。
其实flv也是流式文件,比其它格式更简单,apple同样不支持。。。

目前各家只好都去支持MPEG-TS了,还是apple nb

另外,用TS做流媒体封装还有一个好处,就是不需要加载索引再播放,大大减少了首次载入的延迟
如果片子比较长,mp4文件的索引相当大,影响用户体验(虽然标准支持moov tag压缩,目前没有什么好的压缩工具,客户端也不都一定支持),这也是为什么apple推荐长片用ts流,qiyi也换成了ts流
2011-05-27 4 条评论    

杜嵩,曾绝望得写过视频网站框架的程序员

1 票,来自 蒋頔斐
TS比MP4更方便缓存,便于提高边际缓存服务器性能;随着Android 3.0发布,Pantos(m3u8/ts)正在成为事实标准。
2011-05-24 6 条评论    

derrick,混互联网的

1 票,来自 梁峰
apple强制要求10分钟以上视频使用http live streaming
2011-05-24 4 条评论    

花满楼,阳光灿烂的日子

1 票,来自 梁峰
apple审核严格要求的,超过10分钟的视频只能用http live streaming,否则上不了架。
2011-05-25 1 条评论    

刘孛,P2P,流媒体

1 票,来自 知乎用户
Apple推HLS,Adobe推HDS,微软推SmoothStreaming,Google在Android上从了Apple,在Chrome上据说是要推“更好的”DASH,FMP4现在也能实现流化播放,Adobe和微软的都是基于FMP4的。
其实是寡头们故意营造的壁垒而已,要在Apple的玩具上实现最佳体验,肯定是得按Apple的游戏规则来,与技术优劣无关。
如果非要分个高下,我会说是SmoothStreaming,Silverlight虽然死了,但是这个东东已经顺利的坐上了Windows 8的头等舱。微软现在虽然被搞得比较狼狈,但是老底子在那里,论东西精细度,还是它的强。
2012-07-21 1 条评论    

沈悦,程序员

流媒体协议一共三种:rtmp,rtsp,http live streaming(apple和adobe各一种)
rtmp是adobe的,rtsp android native支持,http live streaming(以下简称hls)当然是apple主打,后来adobe也终于开窍支持了。
rtmp和rtsp都要求特殊的服务器,例如rtmp要求FMS/red5, rtsp要求darwin等,hls只要普通的server,其好处一楼说的很清楚了。
类似于adaptive streaming的技术hls和rtmp都有,rtsp好像没有。
针对带宽压力,rtmp支持rtmfp协议以利用p2p,不知hls有没有。
本身iphone/ipad肯定支持hls/container/video codec格式的解码硬件加速,android也支持rtsp/container/video codec格式的解码硬件加速,至于rtmp/flv/sorenson h.263等,很悲催的mobile设备上无法硬件加速,所以性能不咋地。所以正常人支持mobile设备播放时,会选择rtsp/mp4/h.264@android or http/ts/h.264@ios
请问一楼,针对pc平台如何使用hls来实现audio/video live streaming?我以前记得HTML5虽然有audio/video tag,但对实时流媒体的支持不咋地,只是对VOD支持还可以。不知现在如何了。
2012-03-14 1 条评论    

周昌,程序开发爱好者

实时流媒体 还有一类对延时要求较为严格的应用:视频监控和视频通话。这类流媒体采用HLS明显是不合适的,一般采用HTTP progressive streaming,Android在4.0开始支持这种流媒体格式。能够支持HPS的容器必须是流式的,如FLV, MKV, Android将支持WEM(即MKV)容器,携带VP8视频格式。

因此选择流媒体传输方式还有一个就是 HPS .
2012-03-14 2 条评论    

clonepig,engineer

android ice cream也已经原生支持 hls.而且 使用ts切片方式 可以很容易实现流加密处理。mp4新规范实际已经支持无缝拼接,真正流媒体封装器。
2012-07-19 添加评论    

gavin lee,测试工程师

TS流同类的是RTP流,和MP4有什么关系?TS流、RTP流不是一种打包方式么?不管是TS流、RTP流都可以保存为MP4格式,或者H264格式或者其它格式;
粗鄙浅见,请大家指教。
2013-03-29 添加评论    

黎乾俊,本人目前做苹果手机版炒股软件,希望多交…

你好,我目前正在做流媒体的点播,刚开始入门,希望能像你请教一些问题,现在特别急用这个,我的qq是303623950,麻烦你加一下,谢谢了,加的时候验证你就写上流媒体就可以了
2013-08-13 添加评论    

孔凡,厚积而待勃发

1 票,来自 蒋頔斐
一楼的给的太多了,简单的说:就是在不增加设备和运营成本的情况下提升用户体验.
2011-05-26 添加评论    

彭宁,混在IPTV / Video / CDN,盯着云计算

一楼的正解,但是TS主要问题在于同等码率下不及有效载荷不及MP4, 所以不及MP4清晰
2012-03-02 添加评论   

原创粉丝点击