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