http://tools.ietf.org/html/draft-pantos-http-live-streaming-08
你说的应该是 HTTP Live Streaming [1] 吧。这个是 Apple 为了提高流播效率开发的技术，特点是将流媒体切分为若干 TS 片段（比如每10秒一段），然后通过一个扩展的 m3u 列表文件将这些 TS 片段集中起来供客户端播放器接收。
这 样做相比使用 RTSP 协议的好处在于，一旦切分完成，之后的分发过程完全不需要额外使用任何专门软件，普通的网络服务器即可，大大降低了 CDN 边缘服务器的配置要求，可以使用任何现成的 CDN。分发使用的协议是最常见 HTTP，代理服务器对这个协议的缓存优化相当成熟，而很少有代理服务器对 RTSP 的进行缓存优化。这对播放（软）实时视频有相当大的优势，因为这样分发后，对源服务器的负载压力小得多。
对于非实时视频，同 样的好处也是存在的：如果你要在一段长达一小时的视频中跳转，如果使用单个 MP4 格式的视频文件，并且也是用 HTTP 协议，那么需要代理服务器支持 HTTP range request 以获取大文件中的一部分。不是所有的代理服务器都对此有良好的支持。而 HTTP Live Streaming 则只需要根据列表文件中的时间轴找出对应的 TS 片段下载即可，不需要 range request，对代理服务器的要求小很多。所有代理服务器都支持小文件的高效缓存。
此外，HTTP Live Streaming 还有一个巨大优势：自适应码率流播（adaptive streaming）。效果就是客户端会根据网络状况自动选择不同码率的视频流，条件允许的情况下使用高码率，网络繁忙的时候使用低码率，并且自动在二者 间随意切换。这对移动设备网络状况不稳定的情况下保障流畅播放非常有帮助。实现方法是服务器端提供多码率视频流，并且在列表文件中注明，播放器根据播放进 度和下载速度自动调整。
至于为什么要用 TS 而不是 MP4，这是因为两个 TS 片段可以无缝拼接（直接文件追加就能播放），播放器能连续播放，而 MP4 文件由于编码方式的原因，两段 MP4 不能无缝拼接，播放器连续播放两个 MP4 文件会出现破音和画面间断，影响用户体验。
前两年我尝试过一个基于 HTML5 < audio > 标签 + CBR MP3 格式 + Icecast 流媒体服务器的网络广播台的网页应用（预想是给 http://apple4.us 做 Livecast 的，就是听众只需要访问一个网页就能够几乎实时听到访谈节目），采用的正是 HTTP Live Streaming 的思路。通过对 MP3 音频流进行帧切分，基本能做到连续播放。唯一问题是浏览器不支持 TS 格式， < audio > 标签在两段 MP3 之前切换时会破音。这样只能对谈话类内容适用，如果播放连续的音乐有时候会听出破绽。
iOS 设备上启用 HTTP Live Streaming 非常简单，也是苹果官方推荐的方式。Adobe 的 Flash 流媒体服务器的新版本也要支持这个技术的 [2]。这样普及开来是好事，用户体验更好、网络压力更低。
