当前位置:   article > 正文

【音视频处理】RTMP、HLS、HTTP-FLV、WebRTC、RTSP的区别?直播协议详解_rtsp hls

rtsp hls

 

大家好,欢迎来到停止重构的频道。

本期我们详细讨论直播的相关协议,包括:HTTP-FLV、HLS、RTMP、Web-RTC、RTSP等等。

我们将会详细介绍这些协议的工作原理、应用场景、及延迟的原因。

我们按这样的顺序讨论​

1、  RTMP、HTTP-FLV 

2、  HLS 

3、  Web-RTC 

4、  RTSP 

RTMP、HTTP-FLV协议

RTMP和HTTP-FLV都是建立在FLV封装之上的。

RTMP一般用作直播源推流HTTP-FLV一般用作直播观看

我们先讨论RTMP,RTMP协议是既可以推流、也可以拉流的协议

RTMP地址是rtmp://开头的,且推流地址与播放地址是一样的。

但是由于浏览器摒弃了Flash播放器,而且据说高并发下可能会出现一些不稳定的问题,所以RTMP一般只用作直播源推流推流到直播CDN等场景。

RTMP协议需要特定的流媒体服务软件,如SRS、加入了RTMP插件的Nginx等。

在往期直播工作原理中讨论过,此类流媒体服务软件实际上就是音视频数据的中转站,数据一般只在内存中循环覆盖,不会写入磁盘。

RTMP协议的延迟是比较低的,大概在1-3秒左右。

RTMP通信是建立在TCP长连接通道上的,在封装音视频数据时会强制切片,限制每个数据包的大小。

强制切片也一定程度保证了实时性。有一定的弱网抵抗能力,因为每个数据包都不会太大,所以当某个数据包校验失败时,重新发送的成本不会太大,但也由于合并数据包会加大CPU压力,所以是有一定的性能消耗的。

RTMP协议还有一些变种协议,如RTMPT、RTMPS等,这里不作展开讨论。

我们再讨论HTTP-FLV协议。

地址是http://开头的,是基于HTTP协议的HTTP-FLV可以简单地理解为RTMP的HTTP协议版本。功能和工作原理上是相似的,上面提到的RTMP切片数据功能HTTP-FLV也是有的。

但是,HTTP-FLV协议一般只能用作拉流观看

HTTP-FLV协议的延迟也是比较低的,大概在1-3秒左右,但实际体验下来 HTTP-FLV延迟会略高于RTMP,但是HTTP-FLV相对RTMP适配更多的播放场景。

HTTP-FLV直播流一般需要需加入插件才能播放,如网页需要引入flv.js后,浏览器才能播放。HTTP-FLV直播流,这里需要特别感谢B站开源的flv.js,它促进了HTTP-FLV在浏览器的普及。

HTTP-FLV协议需要特定的流媒体服务软件,如加入了HTTP-FLV插件的Nginx等。

值得一提的是,Nginx的HTTP-FLV插件是包含RTMP功能的,所以一般HTTP-FLV的流媒体服务,推流是以RTMP协议,拉流是用HTTP-FLV协议。

现在比较流行的方案是,直播源推流是RTMP协议,直播拉流观看是HTTP-FLV协议。

HLS协议

HLS协议一般只用作拉流观看,但是从严格意义上讲,HLS协议并不是流式协议。

它工作原理很简单,就是通过HTTP协议下载静态文件

不同的是,HLS协议的文件由两部分组成,一是多个只有几秒长度的.ts碎片视频文件,另一个是记录这些视频文件地址的.m3u8索引文件,且这些静态文件都是直接写入磁盘的。

更具体的说,HLS观看地址是以http://开头、.m3u8结尾的,实际上这个地址就是索引文件的地址,客户端获取到索引文件后,就可以下载对应的碎片视频文件并开始播放了。

由于HLS协议实际上是通过HTTP协议请求文件的,且HLS相关文件是直接写入磁盘的,所以并不需要特殊的流媒体服务软件,使用Nginx等HTTP服务就可以了

HLS协议可以用于点播和直播观看,其适配多种播放场景,一般加入插件就可以播放了,如网页加入HLS的js插件就可以播放了,苹果设备是原生支持HLS协议的。

 

点播的场景下,也就是普通网络视频观看的场景下。

.m3u8索引文件会记录所有的碎片视频文件地址,HLS在点播的场景下,优势是更加明显的。

由于HLS的相关文件是无状态的静态文件,且每个文件的大小是有限的,所以负载均衡、CDN加速的效果更佳明显。

HLS协议的点播视频,会比.mp4、.flv的视频更快地播放出来,且在加载中跳转视频也会更加顺滑。

 

直播的场景下,转码软件可以直接生成HLS相关文件到磁盘,客户端通过HTTP服务下载文件即可。

另外,也可以在Nginx加入RTMP插件,转码软件以RTMP协议推流到Nginx,再由Nginx生成HLS相关文件。

其中,后一种方案更加推荐,因为它对于前期研发和后期对接直播CDN的过度更加顺滑。

 

另外,直播场景下的HLS相关文件与点播是有些不同的

视频流数据每几秒会打包成一个以.ts为后缀的碎片视频文件,每生成一个新的视频文件都会同步更新.m3u8索引文件

且碎片视频文件的个数是有上限的,当达到上限后,默认会将最旧的视频文件删除且更新.m3u8索引文件。

所以在直播的场景下,客户端也需要不断定时重新获取.m3u8索引文件。

 HLS协议在直播的场景下是没什么优势的。

虽然HLS协议的直播流也可以适配很多播放场景,但是由于需要生成静态文件,直播延迟很大大概在5-30秒左右,使用直播CDN的话,由于边缘节点同步等问题,直播延迟甚至可能会达到1分钟左右。

当然HLS协议也有一定的优势,在直播时移,也就是直播转点播,或者录播,也就是点播转直播的场景, 理论上只需要修改索引文件就可以了。

 

另外,HLS协议的.m3u8索引文件支持二级索引,就是高清、标清、流畅等多个观看地址可以整合到一个索引文件。播放器可以根据当前带宽自动切换不同的观看地址,大部分网页播放器的“自动”也是因为这个。

 

这里补充一个HLS协议的小知识点。

由于HLS协议的视频文件、索引文件都是直接写入磁盘的 ,所以如果长时间且多个直播流同时处理,会造成磁盘写入压力过大,机械磁盘可能会磁道会损坏,固态硬盘的寿命会加速衰减。

这种情况下,最好挂载一段内存空间作为HLS相关文件的写入位置,则不会造成磁盘写入压力过大的问题。

补充说明一下,HLS协议是苹果推出的标准,与HLS协议类似的还有MPEG-DASH协议 HLS、MPEG-DASH的工作原理都是差不多的,只是局部标准不一样,这里不作展开。

 

WebRTC协议 

WebRTC协议其实并不是为了直播场景而设计的,WebRTC是一种点对点的视频/语音通话协议。

由于WebRTC是基于UDP的,建立通信后,会不断以流式发送数据,所以延迟会比RTMP还要低。

在一些交互性较高的直播场景,如直播带货等场景,会使用WebRTC作为推流和观看协议 WebRTC的延迟理论上可以达到1秒内。

WebRTC协议支持推流和拉流,地址一般是以webrtc://开头的,且推流和拉流地址一般也是一样的。

WebRTC虽然是点对点的协议,但是应用在直播场景的话,是需要搭建WebRTC服务器作为流媒体服务的,流媒体服务软件可以使用SRS。

这里顺便一提,SRS是国内研发的一个比较流行的开源流媒体服务软件,目前4.0已经囊括了RTMP、HLS、WebRTC、HTTP-FLV等主流协议。 

RTSP协议 

RTSP一般不用作直播场景,RTSP一般用作摄像头、监控等硬件设备的实时视频流观看与推送上。

尽管RTSP协议也支持推流/拉流,且支持TCP、UDP切换以及其他诸多优点。

但是泛用性不足,特别是现在的浏览器都不支持RTSP的播放。

 

总结

以上是常用的直播协议的介绍,其中提到的延迟都是单纯的通信延迟,如果要放眼整个直播流程,延迟将会进一步放大。

因为直播延迟包括推流延迟、转码延迟、拉流延迟,即使使用WebRTC作为推流和拉流协议,最终的延迟也会有几秒的延迟。

至于直播延迟的问题,虽然以上协议起了关键作用,但是往往起不到绝对作用。

直播延迟的降低,会涉及到很多问题。如禁止B帧、GPU硬件加速、流媒体服务缓存I帧、码率限制等等细节问题,后续我们会出具体内容详细讨论。

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/小丑西瓜9/article/detail/195105
推荐阅读
相关标签
  

闽ICP备14008679号