1. 视频协议

1.1. 1. RTSP/RTP/RTCP 协议族

本协议族是最早的视频传输协议。其中 RTSP 协议用于视频点播的会话控制，例如发起点播请求的 SETUP 请求，进行具体播放操作的 PLAY、PAUSE 请求，视频的跳转也是通过 PLAY 请求的参数支持的。而 RTP 协议用于具体的视频数据流的传输。RTCP 协议中的 C 是控制的意思，用于在视频流数据之外，丢包或者码率之类的控制。

该协议族 RTSP 是建立在 TCP 之上的，RTP、RTCP 建立在 UDP 之上。不过也可以通过 interleave 的方式，将 RTP 和 RTSP 一起在同一个 TCP 连接上传输。 RTSP 协议族，是最早被提出来的，因此很多考虑的地方，都还带有早期的特征。比如使用 UDP，是考虑到传输的效率，以及视频协议本身对丢包就有一定的容忍度。但是 UDP 协议，显然不能用于更大规模的网络，而且复杂网络下路由器的穿透也是问题。从视频角度而言，RTSP 协议族的优势，在于可以控制到视频帧，因此可以承载实时性很高的应用。这个优点是相对于 HTTP 方式的最大优点。H.323 视频会议协议，底层一般采用 RTSP 协议。RTSP 协议族的复杂度主要集中在服务器端，因为服务器端需要 parse 视频文件，seek 到具体的视频帧，而且可能还需要进行倍速播放（就是老旧的 DVD 带的那种 2 倍速，4 倍速播放的功能），倍速播放功能是 RTSP 协议独有的，其他视频协议都无法支持。缺点，就是服务器端的复杂度也比较高，实现起来也比较复杂。

1.2. 2. HTTP 协议

HTTP 的视频协议，主要是在互联网普及之后。在互联网上看视频的需求下形成的。

2.1 最初的 HTTP 视频协议，没有任何特别之处，就是通用的 HTTP 文件渐进式下载。本质就是下载视频文件，而利用视频文件本身的特点，就是存在头部信息，和部分视频帧数据，就完全可以解码播放了。显然这种方式需要将视频文件的头部信息放在文件的前面。有些例如 faststart 工具，就是专门做这个功能的。但是最为原始的状态下，视频无法进行快进或者跳转播放到文件尚未被下载到的部分。这个时候对 HTTP 协议提出了range-request的要求。这个目前几乎所有 HTTP 的服务器都支持了。range-request，是请求文件的部分数据，指定偏移字节数。在视频客户端解析出视频文件的头部后，就可以判断后续视频相应的帧的位置了。或者根据码率等信息，计算相应的为位置。

2.2 支持 HTTP range-request 的服务器，目前就可以支持我们一般网络看视频的要求了。但是，这种方式，无法支持实时视频流，或者准实时视频流。因为视频流，是不存在一个视频文件的概念的。HTTP 协议播放视频的好处，就是简单。采取通用的 HTTP 服务器，就可以提供服务，不需要专门类型的服务器，也不需要特别的网络端口，穿过路由器防火墙一点都没有问题。而且还可以利用通用的 CDN 来简化视频的部署分发的工作，减少带宽的使用。这个是目前用于PC 端或者网页端，视频点播业务，最常见的解决方案。客户端的实现，一般采用 flash 完成，flash 本是的 videoplayer 或者 videodisplay 控件就可以完成。资源一般采用 flv 格式，也可以使用 mp4 格式。在此基础上，多家公司推出了自己的解决方法。

2.3 HLS HDS MSS DASH 苹果推出的 HTTP Live Streaming，就是随着苹果设备的普及得以广泛应用的一种。从名词就可以判断出来，HLS 支持 Live 直播式的视频传输。HTTP 采用 m3u8 作为索引文件，视频为 MPEG2-TS 格式的片段文件。如果为直播视频流，则采取更新 m3u8 文件，从而更新视频索引列表，达到视频直播的目的。但是这种方法，因为最终视频是片段文件，所以必然存在片段视频长度的延迟。因此只可以用于对实时性要求没有那么高的准实时视频流。但是 HLS 方式，因为采用了较早的 MPEG2-TS 格式，这种格式的 overhead，也就是头部信息占据总文件的比例比较大，也就是效率不够高。之所以没有使用其他格式，主要是商业竞争和版权的问题。相应的，adobe 公司，推出相似的 HTTP dynamic streaming。这种方式本质和 HLS 的策略是类似的，就是通过索引文件+视频片段的方式。但是显然采用的索引格式和视频片段格式都不一样的。HDS 采用的是视频格式是 flv 或者 f4v，索引格式记不清楚了。类似的，微软也推出了 Microsoft Smooth Streaming，也即是 mss 的视频播出方式，采用的视频格式是分段 mp4 格式。 MPEG 标准组则推出了 Dynamic Adaptive Streaming over HTTP, DASH.采用的视频格式为 3GPP 吧。显然，这个目前是百花齐放的状态，虽然最常用的的是 HLS，谁叫苹果这么霸气呢。而安卓和苹果上面对于 flash 都有限制，而 HDS 是 adobe 推出在 adobe 平台上面的。mss，只有在少数几个地方见到过。dash，目前仅仅是论文里面的产物。以上的协议，主要是解决一个问题，就是自适应码率切换，上面的 dynamic，adaptive 都是类似的意思。主要是利用索引文件中同时给出不同码率的视频文件的地址，这样播放器端，可以根据带宽情况，自适应选择不同码率的视频文件。同时在视频直播方面，在安卓和 iOS 平台以外，还有很多视频服务器提供厂商，自己开发协议，一般采用方式为固定时间片段的 flv 文件的方式（采用 flv，是因为 flash 上方便播放）

2.4 HTML5 同时 HTML 制定厂商也不寂寞，推出 HTML5 这种方式，这种方式本质上，和前面的 HTTP 视频协议没有任何区别。但是播放器端，不再依赖于特定的插件如 flash，或者其他播放软件，而是可以支持浏览器的直接视频播放。采用的是 html 中嵌入 video 标签，同时直接指明视频的 url。不过，不同的浏览器，对于音视频的格式支持不完全相同。比较通用的是视频 H。264 格式，音频 AAC 格式，封装格式 MP4。

2.5 其他 在 HTTP 协议的基础上，各家公司，针对自己的业务特性，也可能开发自己的专有的数据格式，或者协议。但是都是在上述的基本上做出一些细微的修改而已。毕竟国内的技术体系，还完全无法提出一个新的技术的程度。（google，就提出新的编码格式替换 H.264,SPDY 协议，这个国内做不到的）。一般只会做到例如 HTTP 特殊字段或者特殊参数，传递到 flash 中做出一定的解释。或者在原有的视频文件格式基础上添加一些特殊意义的头部等等。

1.3. 3. RTMP

这个是 adobe 公司自己推出的视频播放协议。需要专用的服务器，如 FMS，开源的有 red5.这种协议也是 flash 默认支持的。

总体来看，视频相关的协议发展，是从专用的协议、服务器，逐渐向 HTTP 过渡的过程。而且逐渐适应网络的发展和需求，复杂多变的网络环境，才催生了 http 的视频协议。