把整个流分成一个个小的基于HTTP的文件来下载，每次只下载一些。当媒体流正在播放时，客户端可以选择从许多不同的备用源中以不同的速率下载同样的资源，允许流媒体会话适应不同的数据速率。在开始一个流媒体会话时，客户端会下载一个包含元数据的extended M3U (m3u8)文件，即切片索引文件，用于寻找可用的媒体切片。

视频相关的协议有很多，不同的公司，甚至有自己的协议标准。本文尽量涵盖目前常见的视频相关的协议。
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协议独有的，其他视频协议都无法支持。
缺点，就是服务器端的复杂度也比较高，实现起来也比较复杂。
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中做出一定的解释。或者在原有的视频文件格式基础上添加一些特殊意义的头部等等。
3，RTMP
这个是adobe公司自己推出的视频播放协议。需要专用的服务器，如FMS，开源的有red5.这种协议也是flash默认支持的。