几种直播流媒体协议

题外话：

HTTP渐进下载流媒体播放:  基于TCP。

yy、乐视、爱奇艺、优酷土豆、搜狐视频、花椒直播，主要仍是经过rtmp&hls来实现的，

但他们也意识到rtmp的天生缺陷，因此不论是技术预研也好，仍是测试版也好，都已经或多或少在弄WebRTC了。

   

流媒体概述：

所谓流媒体是指采用流式传输的方式在 Internet 播放的媒体格式。 
流媒体又叫流式媒体，它是指商家用一个视频传送服务器把节目当成数据包发出，传送到网络上。
用户经过解压设备对这些数据进行解压后，节目就会像发送前那样显示出来。
流媒体以流的方式在网络中传输音频、视频和多媒体文件的形式。
流媒体文件格式是支持采用流式传输及播放的媒体格式。
流式传输方式是将视频和音频等多媒体文件通过特殊的压缩方式分红一个个压缩包，
由服务器向用户计算机连续、实时传送。在采用流式传输方式的系统中，用户没必要像非流式播放那样等到整个文件
所有下载完毕后才能看到当中的内容，而是只须要通过几秒钟或几十秒的启动延时便可在用户计算机上利用
相应的播放器对压缩的视频或音频等流式媒体文件进行播放，剩余的部分将继续进行下载，直至播放完毕。

   

RTP :(Real-time Transport Protocol)

是用于Internet上针对多媒体数据流的一种传输层协议.RTP 协议和 RTP 控制协议 RTCP 一块儿使用，
并且它是创建在 UDP 协议上的.
RTP 不像http和ftp可完整的下载整个影视文件，它是以固定的数据率在网络上发送数据，客户端也是按照这种速度观看影视文件，当
影视画面播放事后，就不能够再重复播放，除非从新向服务器端要求数据。

   

RTCP:Real-time Transport Control Protocol 或 RTP Control Protocol或简写 RTCP)

实时传输控制协议,是实时传输协议(RTP)的一个姐妹协议.

注:--:RTP 协议和 RTP控制协议(RTCP) 一块儿使用，并且它是创建在UDP协议上的（通常用于视频会议）

RTSP:(Real Time Streaming Protocol)

实时流媒体会话协议,SDP(会话描述协议)，RTP(实时传输协议)。

是用来控制声音或影像的多媒体串流协议,RTSP 提供了一个可扩展框架，使实时数据，如音频与视频的受控、点播成为可能。
媒体数据使用rtp,rtcp协议。
通常使用udp 做为传输层。适合IPTV场景。
数据源包括现场数据与存储在剪辑中的数据。该协议目的在于控制多个数据发送链接，为选择发送通道，如UDP、多播UDP与TCP提供途
径，并为选择基于RTP上发送机制提供方法
传输时所用的网络通信协定并不在其定义的范围内，服务器端能够自行选择使用TCP或UDP来传送串流内容，比较能容忍网络延迟.


--->:RTSP 与 RTP 最大的区别在于：RTSP 是一种双向实时数据传输协议，它容许客户端向服务器端发送请求，如回放、快进、倒退等操做。当
然，RTSP 可基于 RTP 来传送数据，还能够选择 TCP、UDP、组播 UDP 等通道来发送数据，具备很好的扩展性。它时一种相似与http协议
的网络应用层协议.

WebRTC:

web端实现流媒体的协议。google刚推出WebRTC的时候巨头们要么冷眼旁观，要么抵触情绪很大。使用RTP协议传输。

   

RTMP(Real Time Messaging Protocol)

Macromedia 开发的一套视频直播协议，如今属于 Adobe。和 HLS 同样均可以应用于视频直播，基于TCP不会丢失。
// 区别是 RTMP 基于 flash 没法在 iOS 的浏览器里播放，可是实时性比 HLS 要好。
实时消息传送协议是 Adobe Systems 公司为 Flash 播放器和服务器之间音频、视频和数据传输开发的开放协议.
 // iOS 代码里面通常经常使用的是使用 RTMP 推流，可使用第三方库 librtmp-iOS 进行推流，librtmp 封装了一些核心的 API 供使用者调用
RTMP 协议也要客户端和服务器经过"握手"来创建 RTMP Connection，而后在Connection上传输控制信息。RTMP 协议传输时会对数据格式化，而实际传输的时候为了更好地实现多路复用、分包和信息的公平性，发送端会把Message划分为带有 Message ID的Chunk，每一个Chunk多是一个单独的Message，
也多是Message的一部分，在接受端会根据Chunk中包含的data的长度，message id和message的长度把chunk还原成完整的Message，从而实现信息的收发。

HLS:HTTP Live Streaming(HLS)

是苹果公司(Apple Inc.)实现的基于HTTP的流媒体传输协议，

可实现流媒体的直播和点播 ,主要应用在iOS系
统，为iOS设备(如iPhone、iPad)提供音视频直播和点播方案。
HLS 点播，基本上就是常见的分段HTTP点播，不一样在于，它的分段很是小。
相对于常见的流媒体直播协议，例如RTMP协议、RTSP 协议、MMS 协议等，HLS 直播最大的不一样在于，直播客户端获取到的，并非一个完
整的数据流。
HLS 协议在服务器端将直播数据流存储为连续的、很短时长的媒体文件(MPEG-TS格式)，而客户端则不断的下载并播放这些小文件，
由于服务器端老是会将最新的直播数据生成新的小文件，这样客户端只要不停的按顺序播放从服务器获取到的文件，就实现了直播。
因而可知，基本上能够认为，HLS 是以>>点播的技术方式来实现直播<<。因为数据经过 HTTP 协议传输，因此彻底不用考虑防火墙或者代理的问
题,并且分段文件的时长很短，客户端能够很快的选择和切换码率，以适应不一样带宽条件下的播放。不过HLS的这种技术特色，决定了它的
延迟通常老是会高于普通的流媒体直播协议。
// iOS和 Android 都自然支持这种协议，配置简单，直接使用 video 标签便可

***VLS ：是一种流服务器，专门用来解决流的各类问题，它也具备一些 VLC 的特征。 videolan 做为服务器能够输出http，rtp，rtsp的流。


原则上，RTSP，RTMP，HTTP 均可以作直播和点播，但通常作直播用 RTSP和RTMP，作点播用 HTTP。咱们选用的是RTMP协议。

 

各类协议延时及其缘由

rtmp和httpflv：这两种协议大体数据一致，因此延时缘由都是差很少的。按理说tcp流式传输直播因该都是延时极低的，为何rtmp和httpflv还有延时呢？缘由在h264上，rtmp和httpflv都是传输的flv tag，视频tag的数据日常就是h264数据，h264解码有个IBP，I是关键帧，是一帧完整的图像，必需要先有个I才能解码后面的BP，BP帧能够随便少，可是I帧不能少，因此I帧必须是在flv tag传输中第二个传输的（第一个是h264spspps），可是I帧在h264流里不是常有的，是隔一段才有个I帧，这个一段的间隔，俗称GOP，当编码时候GOP设置很短，当客户端链接上来，服务器会以最快速度找到流中最近I帧，从I帧开始发送直播数据，然而当GOP很长，I帧间隔很长，或者等待下一个I帧开始向新链接发送数据，或者在缓存里找最近的上一个I帧开始发送，这里就是rtmp和hls协议延时的关键了，在各大cdn平台，叫"rtmp秒开技术"，原理就是将推流数据二次解编码，设置很小的gop。总的来讲，gop设置1s，在不考虑网络传输链路延时状况，数据延时最大就为1s，运气好恰好就是I帧就是0延时！

   

 

 

转自：http://blog.csdn.net/u011216417/article/details/72835402