| 直播协议 | 优势 | 劣势 |
|---|---|---|
| RTP /RTCP | RTP 实行有序传送,RTP中的序列号允许接收方重组发送方的包序列，同时序列号也能用于决定适当的包位置，如在视频解码中，就不需要顺序解码。RTCP的主要功能是为RTP所提供的服务质量提供反馈，例如：RTP传输字节数，传输分组数，丢失分组数，单向和双向网络延迟等。网络应用程序可以利用RTCP所提供的信息来提高服务质量，比如限制流量或改用压缩比小的编解码器 | RTP载荷的最大尺寸为1460字 节。以H264 为例，如果一帧数据大于1460，则需要分片打包，然后到接收端再拆包，组合成一帧数据，进行解码播放。 |
| RTSP:(Real Time Streaming Protocol)实时流协议 | RTSP 是一种双向实时数据传输协议，它允许客户端向服务器端发送请求，如回放、快进、倒退等操作。而且，RTSP 可基于RTP 来传送数据，还可以选择 TCP、UDP、组播 UDP 等通道来发送数据，具有很好的扩展性 | 1.服务端实现复杂。2.代理服务器弱：数量少，优化少3. 无路由器防火墙穿透。4. 管流分离：需要1-3个通道 |
| RTMP协议(Real Time Messaging Protocol)实时消息传输协议 | RTMP是Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据传输开发的开放协议。该协议基于TCP，RTMP是一种设计用来进行实时数据通信的网络协议，主要用来在Flash/AIR平台和支持RTMP协议的流媒体/交互服务器之间进行音视频和数据通信。1.速度快，误码率低，延迟低 。2.RTMP 是专为流媒体服务而生，协议在制定的时候就考虑到很多底层的优化3.消息块的传输能够提供更加稳定的直播环境，在硬件上要求会更高，但是却能够缓解http的繁琐的传输介质 | 1.不支持Html5传播、浏览器推送 2.基于TCP协议,虽然开发难度大，推广度还不够，对于开发人员来说门槛比较高 3.硬件要求相较于HLS较高。 4. 协议复杂：开发者写起来累，效率也不行。5.Cache麻烦：流协议做缓存不方便。 |
| HTTP-FLV协议 | FLV协议由Adobe公司主推，即将音视频数据封装成 FLV，然后通过 HTTP 协议传输给客户端，格式极其简单，只是在大块的视频帧和音视频头部加入一些标记头信息，在延迟表现和大规模并发方面都很成熟。但是在手机浏览器上的支持非常有限，但是用作手机端APP直播协议却异常合适。 | 1.需要http长连接 2.h5中需要使用插件。3.需要flash技术支持，不支持多音频流，多视频流，不便于拖动 |
| HLS协议 | HLS协议苹果推出，将视频分成5-10秒的视频小分片，然后用m3u8索引表进行管理，由于客户端下载到的视频都是5-10秒的完整数据，故视频的流畅性很好，但也同样引入了很大的延迟(HLS的一般延迟在10-30s左右)。实际上还是纯“文本协议”相比于FLV，HLS在iPhone和大部分android手机浏览器上的支持非常给力。HLS协议客户端支持简单, 只需要支持 HTTP 请求即可, HTTP 协议无状态, 只需要按顺序下载媒体片段即可，而且网络兼容性好, HTTP 数据包也可以方便地通过防火墙或者代理服务器。但是相比RTMP 这类长连接协议, 用到互动直播场景延时较高。 | 相比 RTMP 这类长连接协议, 延时较高, 难以用到直播场景。对于点播服务来说, 由于 TS 切片通常较小, 海量碎片在文件分发, 一致性缓存, 存储等方面都有较大挑战，小文件碎片化严重 |
直播协议hls，rtmp，http flv，rtsp
| 协议 | 传输方式 | 视频封装格式 | 延时 | 数据分段 | HTML5直播 | 应用场景 |
|---|---|---|---|---|---|---|
| HLS | Http流 | ts文件 | 10~30s | 切片 | 支持 | H5直播，游戏直播 |
| RTMP | tcp流 | flv tag | 2s~5s | 连续流 | 不支持 | 互动直播 |
| http flv | HTTP流 | flv | 2s~5s，优于rtmp | 连续流 | 支持 | 互动直播 |
| rtsp | tcp/udp流 | flv | 一般做到500ms以下 | 连续流 | 不支持 | 互动直播 |
网友评论