直播协议详解 RTMP、HLS、HTTP-FLV、WebRTC、RTSP

直播协议详解 rtmp、http-flv、hls、web-rtc、rtsp 

本期我们详细讨论直播的相关协议,包括:HTTP-FLV、HLS、RTMP、Web-RTC、RTSP等等。
我们将会详细介绍这些协议的工作原理、应用场景、及延迟的原因。
我们按这样的顺序讨论​:

一、RTMP、HTTP-FLV协议

RTMP和HTTP-FLV都是建立在FLV封装之上的。
RTMP一般用作直播源推流,HTTP-FLV一般用作直播观看。

1.1 我们先讨论RTMP

RTMP协议是既可以推流、也可以拉流的协议。
RTMP地址是rtmp://开头的,且推流地址与播放地址是一样的。
但是由于浏览器摒弃了Flash播放器,而且据说高并发下可能会出现一些不稳定的问题,所以RTMP一般只用作直播源推流、推流到直播CDN等场景。

RTMP协议需要特定的流媒体服务软件,如SRS、加入了RTMP插件的Nginx等。
在往期直播工作原理中讨论过,此类流媒体服务软件实际上就是音视频数据的中转站,数据一般只在内存中循环覆盖,不会写入磁盘。
RTMP协议的延迟是比较低的,大概在1-3秒左右。
RTMP通信是建立在TCP长连接通道上的,在封装音视频数据时会强制切片,限制每个数据包的大小。
强制切片也一定程度保证了实时性。有一定的弱网抵抗能力,因为每个数据包都不会太大,所以当某个数据包校验失败时,重新发送的成本不会太大,但也由于合并数据包会加大CPU压力,所以是有一定的性能消耗的。
RTMP协议还有一些变种协议,如RTMPT、RTMPS等,这里不作展开讨论。

1.2 我们再讨论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的播放。

五、协议对比

RTMP、HLS、HTTP-FLV、ARTC

 
协议类型 延时 优点 缺点 特点 适合端 场景推荐
RTMP 1s~3s 延时低
  • 高并发下不稳定
  • iOS平台要开发支持相关协议的播放器
  • 使用非标准TCP端口
TCP长连接 PC端 实时性要求不高的直播
FLV 1s~3s
  • 延时低
  • 可通过HTML5解封包播放
需要集成SDK才能播放 TCP长连接 PC端 实时性要求不高的直播
HLS >10s
  • iOS、Android和H5原生支持良好
  • 可通过HTML5解封包播放
延时高 HTTP短连接 PC端、移动端 实时性要求不高的直播;移动端和H5端
WebRTC 1s
  • 超低延时
  • 抗弱网能力强
H5播放不支持B帧和AAC音频(可通过阿里云RTS转码功能去除B帧并将音频转为Opus) UDP PC端、移动端 实时性要求高的直播,如电商带货、在线教育、社交互动等

 

总结

以上是常用的直播协议的介绍,其中提到的延迟都是单纯的通信延迟,如果要放眼整个直播流程,延迟将会进一步放大。
因为直播延迟包括推流延迟、转码延迟、拉流延迟,即使使用WebRTC作为推流和拉流协议,最终的延迟也会有几秒的延迟。
至于直播延迟的问题,虽然以上协议起了关键作用,但是往往起不到绝对作用。
直播延迟的降低,还涉及到很多问题。如禁止B帧、GPU硬件加速、流媒体服务缓存I帧、码率限制等等细节问题。

原文:https://www.cnblogs.com/eddyz/p/17869403.html

posted @ 2024-04-23 16:47  yangchin9  阅读(3793)  评论(0编辑  收藏  举报