常用的流媒体协议主要有 HTTP 渐进下载和基于 RTSP/RTP 的实时流媒体协议，这二种基本是完全不同的东西，目前比较方便又好用的我建议使用 HTTP 渐进下载的方法。在这个中 apple 公司的 HTTP Live Streaming 是这个方面的代表。它最初是苹果公司针对iPhone、iPod、iTouch和iPad等移动设备而开发的流.现在见到在桌面也有很多应用了， HTML5 是直接支持这个。

我们可以看看 HTTP Live Streaming 是怎么样工作的。平时的直播技术中,播放模式中必须等待整个文件下载完才行，在 HLS 技术中 Web 服务器向客户端提供接近实时的音视频流。但在使用的过程中是使用的标准的 HTTP 协议，所以这时，只要使用 HLS 的技术，就能在普通的 HTTP 的应用上直接提供点播和直播。
要详细了解原理，我们先看看这个所需要的步骤。

视频采集 ->编码器 -> 流分割 -> 普通 web 服务(索引文件和视频文件) -> 客户端

内容准备的过程大约二种，一是视频采集，编码器首先将摄像机实时采集的音视频数据压缩编码为符合特定标准的音视频基本流，也可以拿编码完了的文件，有一点必须保证，就是一定要使用H.264视频和AAC音频，因为发明这个的是苹果公司，只支持这个。然后给这些封装成成为符合MPEG-2(MPEG 2 TS、MPEG2 PS之所以使用这个，主要是因为声音和视频会交织在一起，也会有关键帧来让视频可以直接播放).

流分割部分在这个中，比起 RTSP 之类和普通点播的最大不同，就是他会给 MPEG-2 分割成很多个 ts 的文件。分割过程大多是按时间来切，根据国外的资料，建议切 10s 一个的文件，如果码流高可以 5 秒一次。在分割还有一点不同，就是这时流分割器会生成一个含有指向这些小TS文件指针的索引文件

所以这个文件也必须在 web 服务器上，不能少。每多 10s 时，就会多一个 ts 文件，所以索引也会根着修改成最新的几段视频。

最后，这些切分了的小的一系列的 ts 文件，放到普通的 web 服务器中就行了。这时在 CDN 中也是一样，因为请求这些文件会使用标准的 HTTP 协议。索引文件后缀是.m3u8 ,索引文件采用扩展的M3U播放列表格式,其实就一文本。
内部的视频的地址会是如下

http://media.example.com/s_96ksegment1.ts 
http://media.example.com/s_96ksegment2.ts 
http://media.example.com/s_96ksegment3.ts 

所以这时可以直接做 Cache 和直接放到 Web 服务器中,简单方便。
如果 MIME 的信息输出不对的话，记的要修改这加入 ts 和 m3u8 的后缀支持

.m3u8 application/x-mpegURL 
.ts video/MP2T 

最后就是客户端，如果是 HTML 直接在 HTML5 中直接支持这种视频可以使用如下标签

<video tabindex="0" height="480" width="640"> 
 <source src="/content1/content1.m3u8"> 
</video> 

如果是应用客户端(Safari QuickTime之类)，就得装软件来支持，客户端会根据选择的流的索引来下载文件，当下载了最少二段后开始播放。直接 m3u8 的索引结束。另外，HTTP可以设计成的自适应比特率流，在不同网络环境，选择下载不同码流的视频。

所以整个 HTTP Live Streaming 无论是直播还是点播，都能做到近似实时的方式来进行流播放。理论的最小时延是每个切片的长.

目前本协议加入了 IETF 的草案建议 http://tools.ietf.org/id/draft-pantos-http-live-streaming-01.txt

如果网站也想使用这种来做视频请看 iPhone HTTP 流与 FFMpeg 和开放的源 Segmenter
http://www.ioncannon.net/programming/452/iphone-http-streaming-with-ffmpeg-and-an-open-source-segmenter/

Akamai http://iphone.akamai.com/

白皮书 (http://bbs.rosoo.net/thread-9764-1-1.html)