3.简述HLS,HTTP,RTSP,RTMP协议的区别
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,安卓原生支持。
缺点:延迟性比较大。楼上说的切片,关键帧改变后切片时间可以缩短,而且可以自己设定首次产生多少分片。
目前几种视频流的简单对比:
协议 |
httpflv |
rtmp |
hls |
dash |
传输方式 |
http流 |
tcp流 |
http |
http |
视频封装格式 |
flv |
flv tag |
Ts文件 |
Mp4 3gp webm |
延时 |
低 |
低 |
高 |
高 |
数据分段 |
连续流 |
连续流 |
切片文件 |
切片文件 |
Html5播放 |
可通过html5解封包播放(flv.js) |
不支持 |
可通过html5解封包播放(hls.js) |
如果dash文件列表是mp4webm文件,可直接播放 |
-
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.drag.test,.com/live/livestream.flv, HTTP 交互如下:
请求:
GET/live/livestream.flv?wsHost=flv.drag.test, com HTTP/1.1
accept:*/*
accept-encoding:gzip,
accept-language:zh_CN
connection:Keep-Alive
host:www.abc.com
referer:http: //www.abc.com/vplayer.swf
响应:
HTTP/1.1 2000K
Content-Type: video/χ-fIv
Http_flv & RTMP
这两个协议实际上传输数据是一样的,数据都是flv文件的tag。http_flv是一个无限大的http流的文件,相比rtmp就只能直播,而rtmp还可以推流和更多的操作。但是http有个好处,就是是以80http通信的,穿透性强,而且rtmp是非开放协议。
这两个协议是如今直播平台主选的直播方式,主要原因就是延时极低。
将测试:RTMP延迟1s左右,HTTPFLV延迟1-2s左右,可用于对延迟要求比较苛刻的场景,但要注意兼容性,文章最后会说明HTTPFLV兼容性。
HTTP FLV直播Demo:
<!DOCTYPE html> <html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> <title>flv.js demo</title> <style> .mainContainer { display: block; width: 1024px; margin-left: auto; margin-right: auto; } .urlInput { display: block; width: 100%; margin-left: auto; margin-right: auto; margin-top: 8px; margin-bottom: 8px; } .centeredVideo { display: block; width: 100%; height: 576px; margin-left: auto; margin-right: auto; margin-bottom: auto; } .controls { display: block; width: 100%; text-align: left; margin-left: auto; margin-right: auto; margin-top: 8px; margin-bottom: 10px; } .logcatBox { border-color: #CCCCCC; font-size: 11px; font-family: Menlo, Consolas, monospace; display: block; width: 100%; text-align: left; margin-left: auto; margin-right: auto; } </style> </head> <body> <div class="mainContainer"> <video name="videoElement" class="centeredVideo" id="videoElement" controls width="1024" height="576" autoplay> Your browser is too old which doesn't support HTML5 video. </video> </div> <script src="./flv.js?v=2"></script> <script> if (flvjs.isSupported()) { startVideo() } function startVideo(){ var videoElement = document.getElementById('videoElement'); var flvPlayer = flvjs.createPlayer({ type: 'flv', isLive: true, hasAudio: true, hasVideo: true, enableStashBuffer: true, url: 'https://xl.live-play.acgvideo.com/live-xl/520658/live_12860646_332_c521e483.flv?wsSecret=778d91efcb22c588be28cb67ebe57082&wsTime=1510929009' }); flvPlayer.attachMediaElement(videoElement); flvPlayer.load(); flvPlayer.play(); } videoElement.addEventListener('click', function(){ alert( '是否支持点播视频:' + flvjs.getFeatureList().mseFlvPlayback + ' 是否支持httpflv直播流:' + flvjs.getFeatureList().mseLiveFlvPlayback ) }) function destoryVideo(){ flvPlayer.pause(); flvPlayer.unload(); flvPlayer.detachMediaElement(); flvPlayer.destroy(); flvPlayer = null; } function reloadVideo(){ destoryVideo() startVideo() } </script> </body> </html>
flv.js问题:(暂时发现这几个)
1. 播放一段时间后,音视频不同步
2. 播放一段时间后,音频模糊
3. 暂停后继续播放是接着暂停时的场景继续播,对于直播会产生延迟 =》 临时解决方案:暂停后继续播放时,手动销毁视频再重新加载播放
4. 手机端兼容性差
--------------------------------------------
1,2 问题解决方案:
尝试设置 config.fixAudioTimestampGap = false
控制台将不会输出大量警告信息。
经检测,不同的推流客户端,会导致音视频同步问题有不一样的体现。
LFLiveKit 的音频流时间戳问题,定期会有两帧之间存在两倍时间戳差,会导致严重音画不同步。
目前在我们平台,ios客户端音视频均同步,安卓客户端音视频不同步,需要设置flvjs的config.fixAudioTimestampGap = false才会音视频同步。
github issue:https://github.com/Bilibili/flv.js/issues/136
----------------------------------------------
判断flv.js在手机端是否支持点播和httpflv直播:
是否支持点播视频:flvjs.getFeatureList().mseFlvPlayback
是否支持httpflv直播流:flvjs.getFeatureList().mseLiveFlvPlayback
目前测试结果:
ios :均不支持,包括微信和safari
安卓:微信均不支持;其他浏览器部分支持点播,全部不支持直播