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
