网站首页 > 技术文章 正文
HLS,HTTP,RTSP,RTMP协议的区别:
- 用HTTP方式: 先通过服务器将FLV下载到本地缓存,然后再通过NetConnection的本地连接来播放这个FLV,这种方法是播放本地的视频,并不是播放服务器的视频。因此在本地缓存里可以找到这个FLV。其优点就是服务器下载完这个FLV,服务器就没有消耗了,节省服务器消耗。其缺点就是FLV会缓存在客户端,对FLV的保密性不好。
是一种将直播流模拟成FLV文件,通过HTTP协议进行下载的模式来实现流媒体传输的协议,端口号80
一般建议使用HTTP FLV,实时性和RTMP相等。
优点:HTTP相比于RTMP省去了一些协议交互时间,首屏时间更短。HTTP可拓展的功能更多。
- 用RTMP方式: 通过NetConnection连接到FMS(Flash Media Server)或Red5服务器,并实时播放服务器的FLV文件,这种方式可以任意选择视频播放点,并不象HTTP方式需要缓存完整个FLV文件到本地才可以任意选择播放点,其优点就是在本地缓存里是找不到这个FLV文件的。其优点就是FLV不会缓存在客户端,FLV的保密性好,其缺点就是消耗服务器资源,连接始终是实时的。
- 由以上分析可知,Http方式是本地播放,而RTMP方式是服务器实时播放.
Adobe公司的流媒体传输协议,端口号1935
普通网络用户均可使用,包括非IOS平台用户,对非80端口(如1935)无限制的网络环境用户。
优点:防HTTP下载,延时短。
- RTSP: RTSP 1.0标准的制订者没有充分预测到互联网带宽的快速增长,以及由于IPv4地址短缺导致的NAT技术的广泛使用,还有代理服务器的大量存在,它在传输可靠性和易用性上都存在一定的缺陷。虽然各家厂商都做了一定程度的修补,比如支持RTSP over HTTP,支持NAT穿透等,但仍然于事无补。在2005之后网络视频大爆炸的几年中,RTSP 1.0并没有得到youtube, hulu, 土豆,优酷等视频服务提供商的青睐,相反,Adobe公司开发的私有流媒体技术RTMP以其优秀的易用性和富媒体的一体化集成,得到了多数视频服务提供商的追捧,成为了事实上的标准.
缺点:web端播放rtsp流的话,需要写插件,而且对浏览器也很挑剔,flash不支持rtsp,需要做activeX插件
目前的CDN都是基于RTMP的
- HLS(Http Living Streaming): 从2010年起,苹果开始在iOS设备上支持一种叫做”Live HTTP”的流媒体技术,并宣布在iOS上不会支持RTSP和Flash技术。Live HTTP本质上跟基于HTTP的文件分段下载很接近。在带宽充裕的前提下,live HTTP能够实现跟RTSP和RTMP同样的流媒体播放效果,同时得到了更好的易用性,更简单的控制。
在最新一代的超文本标识语言HTML5中,视频文件的点播,同样也采用了HTTP作为其承载协议。
HLS
IOS平台下的流媒体传输协议 ,端口号80
优点:H5浏览器支持比较好,IOS,安卓原生支持。
缺点:延迟性比较大。楼上说的切片,关键帧改变后切片时间可以缩短,而且可以自己设定首次产生多少分片。
音视频开发教学视频:【免费】FFmpeg/WebRTC/RTMP/NDK/Android音视频流媒体高级开发-学习视频教程-腾讯课堂
目前几种视频流的简单对比:
- RTMP(Real Time Messaging Protocol)是基于TCP的,由Adobe公司为Flash播放器和服务器之间音频、视频传输开发的开放协议。
- HLS(HTTP Live Streaming)是基于HTTP的,是Apple公司开放的音视频传输协议。
- HTTP FLV则是将RTMP封装在HTTP协议之上的,可以更好的穿透防火墙等。
直播协议的选择:RTMP vs. HLS
想要做一个直播业务,主要包括三个部分:采集推流端、流媒体服务端、播放端。这里不多说,就主要结合 iOS 平台,从观看端出发,介绍一下对直播协议的选择。
通常在 iOS 平台做直播业务,会有两种协议可供选择:HLS 和 RMTP。
- HLS,是苹果公司实现的基于 HTTP 的流媒体传输协议,全称 HTTP Live Streaming,可支持流媒体的直播和点播,主要应用在 iOS 系统,为 iOS 设备(如 iPhone、iPad)提供音视频直播和点播方案。
- RTMP,实时消息传输协议,Real Time Messaging Protocol,是 Adobe Systems 公司为 Flash 播放器和服务器之间音频、视频和数据传输开发的开放协议。协议基于 TCP,是一个协议族,包括 RTMP 基本协议及 RTMPT/RTMPS/RTMPE 等多种变种。RTMP 是一种设计用来进行实时数据通信的网络协议,主要用来在 Flash/AIR 平台和支持RTMP协议的流媒体/交互服务器之间进行音视频和数据通信。
上面是这两种协议的简介,那它们在实际应用中会有什么差异呢?
HLS
先说说 HLS。HLS 的基本原理就是当采集推流端将视频流推送到流媒体服务器时,服务器将收到的流信息每缓存一段时间就封包成一个新的 ts 文件,同时服务器会建立一个 m3u8 的索引文件来维护最新几个 ts 片段的索引。当播放端获取直播时,它是从 m3u8 索引文件获取最新的 ts 视频文件片段来播放,从而保证用户在任何时候连接进来时都会看到较新的内容,实现近似直播的体验。相对于常见的流媒体直播协议,例如 RTMP 协议、RTSP 协议等,HLS 最大的不同在于直播客户端获取到的并不是一个完整的数据流,而是连续的、短时长的媒体文件,客户端不断的下载并播放这些小文件。这种方式的理论最小延时为一个 ts 文件的时长,一般情况为 2-3 个 ts 文件的时长。HLS 的分段策略,基本上推荐是 10 秒一个分片,这就看出了 HLS 的缺点:
- 通常 HLS 直播延时会达到 20-30s,而高延时对于需要实时互动体验的直播来说是不可接受的。
- HLS 基于短连接 HTTP,HTTP 是基于 TCP 的,这就意味着 HLS 需要不断地与服务器建立连接,TCP 每次建立连接时的三次握手、慢启动过程、断开连接时的四次挥手都会产生消耗。
不过 HLS 也有它的优点:
- 数据通过 HTTP 协议传输,所以采用 HLS 时不用考虑防火墙或者代理的问题。
- 使用短时长的分片文件来播放,客户端可以平滑的切换码率,以适应不同带宽条件下的播放。
- HLS 是苹果推出的流媒体协议,在 iOS 平台上可以获得天然的支持,采用系统提供的 AVPlayer 就能直接播放,不用自己开发播放器。
RTMP
相对于 HLS 来说,采用 RTMP 协议时,从采集推流端到流媒体服务器再到播放端是一条数据流,因此在服务器不会有落地文件。这样 RTMP 相对来说就有这些优点:
- 延时较小,通常为 1-3s。
- 基于 TCP 长连接,不需要多次建连。
因此业界大部分直播业务都会选择用 RTMP 作为流媒体协议。通常会将数据流封装成 FLV 通过 HTTP 提供出去。但是这样也有一些问题需要解决:
- iOS 平台没有提供原生支持 RTMP 或 HTTP-FLV 的播放器,这就需要开发支持相关协议的播放器。
协议差别:
- HLS:HTTP Live Streaming;基于短连接 HTTP;集合一段时间的数据生成 ts 切片文件,更新 m3u8 文件;延时 25s+。
- RTMP:Real Time Messaging Protocal;基于长连接TCP;每个时刻收到的数据立即转发;延时 1~3s。
- HTTP-FLV: RTMP over HTTP;基于长连接 HTTP;每个时刻收到的数据立即转发,使用 HTTP 协议;延时 1~3s。
HTTP-FLV的两种方式
目前,有两种Http-Flv的实现方式,一种是基于文件的方式,一种是基于包的方式
两种Http-Flv的相同之处在于,都是HTTP方式输出,都是FLv 格式
两种Http-Flv的不同之处在于:
1、架构上,一个
基于包的架构更偏实时,基于包,基于收到包,转发包。
基于文件的架构,边写文件,边output给用户数据。
2、存储
基于包的架构,一般只使用内存,通常只缓存很少的数据,例如Gop-cache(当前数据帧到上一个IDR帧)
基于文件的架构,通常会使用到存储,可以缓存7天乃至更多的数据,用来实现电视时移回看等应用。
后记:还有一种基于http flv文件的方式也属于http-flv,但不叫hrrp-flv流式直播,可以叫http-flv切片直播。
另外,基于文件方式的HTTP-FLV流式直播补充以下内容:业界常见的另一种HTTP直播协议是将直播流式数据虚拟成为一个无限大的FLV(FLASH VIDEO)文件,并通过HTTP协议进行传输。客户端仅发送一次HTTP GET请求,请求中携带需要访问的直播流名,服务器返回HTTP响应,不携带消息体内容长度直接发送无限长FLV文件内容,或者使用HTTP CHUNK模式将无限长FLV文件按分段模式发送。客户端获得HTTP消息体中的FLV内容时即可播放。
Http_flv & RTMP
这两个协议实际上传输数据是一样的,数据都是flv文件的tag。http_flv是一个无限大的http流的文件,相比rtmp就只能直播,而rtmp还可以推流和更多的操作。但是http有个好处,就是是以80http通信的,穿透性强,而且rtmp是非开放协议。
这两个协议是如今直播平台主选的直播方式,主要原因就是延时极低。
将测试:RTMP延迟1s左右,HTTPFLV延迟1-2s左右,可用于对延迟要求比较苛刻的场景,但要注意兼容性,文章最后会说明HTTPFLV兼容性。
相关视频推荐:【免费】FFmpeg/WebRTC/RTMP/NDK/Android音视频流媒体高级开发-学习视频教程-腾讯课堂
- 上一篇: 从零开始精通RTSP之加密
- 下一篇: Qt 搭建 RTSP 服务器
猜你喜欢
- 2024-11-25 最新FFmpeg RTSP流抓取
- 2024-11-25 WebRTC 拥塞控制 | 网络带宽过载检测
- 2024-11-25 YOLO对象检测算法也这么卷了吗——基于YOLOv8的人体姿态检测
- 2024-11-25 rtsp协议之请求响应示例
- 2024-11-25 rtsp开源服务器之live555
- 2024-11-25 全网最全的抓包工具的综合对比
- 2024-11-25 【开源】音视频并发测试工具
- 2024-11-25 深度学习实战 :智慧工地安全帽和危险区域检测系统(含代码)
- 2024-11-25 NAS部署AI视频卫士,压榨NAS的最后一滴性能,NAS性能检测镜像
- 2024-11-25 Java 监控直播流rtsp协议转rtmp、hls、httpflv协议返回浏览器
你 发表评论:
欢迎- 最近发表
- 标签列表
-
- oraclesql优化 (66)
- 类的加载机制 (75)
- feignclient (62)
- 一致性hash算法 (71)
- dockfile (66)
- 锁机制 (57)
- javaresponse (60)
- 查看hive版本 (59)
- phpworkerman (57)
- spark算子 (58)
- vue双向绑定的原理 (68)
- springbootget请求 (58)
- docker网络三种模式 (67)
- spring控制反转 (71)
- data:image/jpeg (69)
- base64 (69)
- java分页 (64)
- kibanadocker (60)
- qabstracttablemodel (62)
- java生成pdf文件 (69)
- deletelater (62)
- com.aspose.words (58)
- android.mk (62)
- qopengl (73)
- epoch_millis (61)
本文暂时没有评论,来添加一个吧(●'◡'●)