通信人家园

标题: IPTV连载（最新更新于4月20日） [查看完整版帖子] [打印本页]

时间: 2010-4-19 22:18

作者: stonepeter 标题: IPTV连载（最新更新于4月20日）

IPTV连载（一）自适应流的前世今生--（1）多码率流控发展简史

　　自适应流(Adaptive Streaming)是最近流行起来的媒体分发技术，基于自适应流的分发技术因为有诸多的好处所以已经越来越流行起来。很多关心流媒体发展的朋友也在问自适应流到底是一个什么样的东西，对IP电视的未来发展有什么样的关键意义。

　　（1）多码率流控发展简史

　　要明白自适应流，我们不妨先看看多码率流控(Multi Bitrate Streaming)的发展简史。

　　因为早期的国内很多IPTV的解决方案是基于Windows媒体服务器或者是RealNetworks的RealNetwork服务的。我们以微软的流媒体服务发展为例作介绍。

　　a)过去： WMST，MBR和智能流

　　微软在1998年和Windows媒体播放器6.1一起发布了WMST（Windows Media Stream Thining)。WMST已经有点“智能”了，WMST会自动检测网络状况，然后根据响应降低影像的码率，如果没有网络信号的时候，客户端甚至会不放视频，而只播放声音（因为音频流要求的码率更低）。

　　而最早的多码率流控是2000年和Windows媒体播放机6.4一起发布的Windows媒体服务4.0(WMS4.0)以及Wndows媒体服务4.1(WMS4.1)。WMS4.1使用一个ASF文件储存多个不同码率的同一路流，Windows媒体流控协议(WMSP)支持在多个不同的流之间切换。这个技术一般叫做MBR ASF(Multiple Bit Rate ASF-多码率ASF)

　　2002年的时候，微软发布了Windows媒体9系列产品。其中也包括Windows媒体服务9.0以及Windows媒体播放机9.0。Windows媒体9系列发布一个改进版的MBR，叫做“智能流(Intelligent Streaming)”，“智能流”结合了带宽检测，WMST技术，MBR ASF技术，以及一个更好的用于Windows媒体播放机图像处理技术。当然了，“智能流”依然要求媒体文件要编码成MBR ASF文件格式，而且要专用比如说像Windows媒体编码器(Windows Media Encoder)这样的工具才行。

　　这些设计当然很好，但是他们都有天生的不足。他们都只能用于流控，就是说并不能渐进下载，而且只限于微软的媒体服务器。而编码器也不要求影视节目严格的对齐，只是要求关键帧（key-)对齐，这就导致了在同一视频不同码率的流之间作平滑切换变得很困难。媒体流出来的时候都是以固定的码率的，服务器不知道客户端的真实网络情况，要想准确地预测客户端的带宽就几乎不可能了，尤其是在要求实时播放的情况下就更难了。因为，差的网络带宽检测出来的时候就已经滞后了，这时客户端的播放器又不得不暂停下来，选择更合格的低码率的流重新进行缓冲。

　　b)现在：基于HTTP协议的方式分发开始流行起来。

　　过去几年流媒体发展的一个趋势就是希望能转为使用基于HTTP的方式进行内容分发，而不再使用传统的流媒体协议--RTSP，MMS，RTMP等等。目前已经有很多视频网站已经在使用基于HTTP的渐进式下载(Progressive Download)技术进行媒体分发了。

　　这样做的理由很多：

　　1）基于HTTP方式的下载在服务器的构架上会比专门的流媒体服务器下载更便宜；

　　2）流媒体协议通常对防火墙和路由器要特别的要求，UDP包传送的时候会要求特别的网络端口，而不是所有防火墙和路由器都放行的HTTP服务常用的80端口；

　　3）HTTP媒体服务分布的时候不要求特别的代理和缓冲。在HTTP服务器上，媒体文件和其他的别的文件一样直接缓冲在服务器上。

　　4）在边缘网络上搭建一个离最终用户更近的HTTP服务器会更便宜也更容易。

　　虽然媒体协议在设计的时候就已经考虑到了媒体分发时候的问题，但实际情况是因特网搭建和优化的时候都是基于HTTP分布而做的。所以做媒体分发的时候就会常常被问到“为什么流媒体不直接用因特网的HTTP方式去分发，而去要求整个因特网为你的流媒体分发而改变？”

　　Move Networks公司2008年的时候已经在不同的场合证实了，基于HTTP对流媒体是可以进行大规模的分发的，不但可以用于视频点播，还可以用于直播服务，例如用Silverlight作为客户端播放器的Democratic National Convention网站。2008年北京奥运会的时候，在NBC视频网站上，微软再一次证实了用基于HTTP的流媒体的分发是完全可行的，那就是微软的平滑流的技术原型。

　　(待续)

时间: 2010-4-20 10:53

作者: stonepeter 标题: IPTV连载（二）自适应流的前世今生-- （2）流媒体分发技术

　　(2)现今的流媒体分发技术

　　现今网络上的流媒体分发大致有三种方式：传统的流控，渐进式下载以及自适应流。

　　a)传统的流控技术

　　实时流控协议（RTSP，Real-Time Streaming Protocol)是传统流控协议最好的例子。RTSP是有状态的协议，从客户端从一开始连接到流控服务器直到最后和流控服务器断开连接，服务器要保持跟踪客户端的状态。客户端通过发送播放，暂停和断开命令向服务器传送自己的状态。

　　一旦客户端和服务器的会话（Session）建立了，服务器就将媒体固定地传送成一个个小RTP(Real Time Packet)包(这些包的格式是按RTP协议封装的)。通常一个RTP包的大小是1452字节，这意味着视频会编成每秒钟1兆字节的流，每个包里大约有11毫秒的视频内容。在RTSP协议下，这些包会通过UDP或者TCP网络协议进行传送，当网络防火墙或者网络代理阻挡了UDP包的时候才会用TCP协议进行传送，因为TCP包传送的时候会不断重试，直到客户端收到为止，所以用TCP传很明显会增加网络的延迟，而网络延迟增大，就会影响影视的播放质量。

　　（图）RTSP是传统流控协议最好的例子

　　而用HTTP协议是一个无状态的协议。如果一个HTTP客户端请求数据的时候，服务器只要响应然后发回数据就行了，它并不要记得哪个客户端也更不要保存状态。每次HTTP请求都是一个完全的单独的一次性的会话。

　　像RTSP这种最传统的流控协议有如下特点：1）服务器向客户端发送数据包的时候只以某个实时的码率，就是媒体编码时候的码率。例如，一个视频编码成500kbps的视频要求的客户端的接收带宽大约也是500kbs。2）服务器只能提前发送足够多的数据让客户端进行缓冲。通常情况下客户端会缓冲1到5秒钟的影视流。也就是说，如果你把一个节目暂停了10分钟，你重新开始播放的时候还要等大约5秒钟影视流完全下载到了客户端的时候才能看。

　　传统的流控协议还有Adobe公司的RTMP协议(Proprietary Real Time Messaging Protocol)，以及RealNetworks公私的RDT协议(RTSP over Real Data Transport Protocol)。 Adobe公司新开发的用于Flash7.0?的协议动态流控流切换功能还是基于RTMP协议的，所以还是传统的流控协议，还不是自适应流控技术。

　　b)渐进式下载(Progressive Download)

　　如今另一种通过WEB服务器分发媒体的方式就是渐进式下载，渐近式下载其实也就是一种简单的从HTTP WEB服务器进行文件下载的普通方式。大多数媒体播放器和平台都支持渐进式下载，比如说ADOBE FALSH，SILVERLIGHT以及Windows媒体播放机。“渐进”这个术语源于播放器客户端允许媒体文件还正在下载的时候就开始播放，不用等到整个文件下载都完成写到磁盘上之后，通常情况下播放内容都是先直接放在浏览器的缓存里的。支持HTTP1.1标准的客户端可以通过向WEB服务器进行字节范围请求（byte range request)来寻址到没有下载完成的媒体文件的相应位置。

　　现在流行的视频共享网站，比如说YOUTUBE，VIMEO，MYSPACE和MSN SOAPBOX，几乎都是在使用渐进式下载技术。

　　不像流媒体服务器，几乎都只传送差不多十秒钟的数据给客户端。HTTP WEB服务器会在媒体文件下载完成之前一直在传送数据流。如果一开始播放时你就暂停了一个渐进式下载的视频，然后在那等着，就会把整视频个文件都下载到浏览器的缓存里面，这样就可以不停顿、平滑地把整个视频都看完。用这样的下载的方式，一个已经完全下载了的十分钟的视频，就有可能你只看了三十秒钟，因为你并不喜欢这段视频，然后关掉它，其实这样你和你的内容提供商都浪费了九分三十秒的宽带。为了缓解这个问题，IIS7.0提供了一个很酷的技术，叫做码率节阀（Bit Rate Throttling)的技术，允许内容提供商合理限制下载码率到所需要的码率，这样流控服务器就可以减少一些开销。

　　c)基于HTTP的自适应流控

　　自适应流控是一种杂交了流控技术和基于HTTP渐进式下载的分发技术。自适应流控是使用了HTTP而不是新协议的先进的概念。无论是IIS的平滑流控还是MOVE NETWORKS的自适应流都是自适应流控的很好的例子。尽管这两种技术使用了不同的编码方式，不同的格式和不同的加密框架，但他们都是依靠HTTP作为传输协议，然后进行一系列分成很小块的渐进式下载，不再是一个大的渐进式下载。

　　在典型的自适应流控实现中，视频和音频源被切分成很多短的片断（“chunks“--流控块），然后被编码成需要的分发格式。流控块通常有两到四秒长。在视频编码级别，这通常意识着每个流控块被切分成一个视频图像组（GOP（Group of Pictures)）边界（每个流控块都包含一个关键帧），于是就不用依赖过去或者将来的流控块的任何图像组的信息了。这样每个流控块之间就可以独立于其他流控进行解码。

　　这些编码好的流控块放到HTTP WEB服务器上。客户端使用普通的HTTP渐进式下载的方式从WEB服务器上以线性的方式下载它们然后使用。一旦流控块下载到一客户端，客户端就可以顺序的方式对流控块进行播放。因为流控块很小心地进行编码，之间没有任何间隔和重叠，流控块播放起来就是平滑视频了。

　　当视频源用N种码率进行编码，生成N个两到四秒的不同大小的流控块之后，“自适应”部分的解决方案就有用了。客户端现在可以选择不同大小的流控块进行播放。因为WEB服务器只管按照网络带宽尽快地分发数据，客户端可以很容易地计算出用户端的带宽，就可以提前决定下载是大的还是小的流控块。播放和下载的缓冲的大小是完全由客户端定制的。

　　（图2）自适应流控是杂交的媒体分发方式。

　　自适应流控像其他的HTTP分发方式一样，相比传统流控技术有如下优势：

　　1）便宜的分发。因为自适应流控使用统一的HTTP缓存和代理，而且并不需要在每个服务器节点进行特别定制。

　　2）有更好的伸缩能力，减少了“最后一公里”的问题。因为它可以动态地适应劣势的网络条件，而这些网络情况往往发生在离用户家更近的地方。

　　3）观众更好地适应内容，而不是由内容提供者来猜测应当要用用户提供哪种最有可能的码率。

　　对用户来说也有好处：

　　1）快速启动和跳转，因为启动/跳转在使用更高的合适的码率之前，可以用最低的视频码率来开始播放。

　　2）不要等待缓冲，不会中途断开连接，播放时不会卡（一旦用户达到了最小的码率要求）

　　3）基于网络情况和CPU能力的无察觉码率切换

　　4）总之一句话，平滑的播放体验

　　微软在NBC2008年的北京奥运会网站上创建了一个基于HTTP的自适应流控的原型。为了赶上项目的快速开发的进度表，当时项目实现的时候非常直接了当。NBC使用Digital Rapids和Anystream编码器为每个视频源生成了多个不同码率和分辨率的Windows Media Video(WMV)文件。编码器没有使用任何别的新的编码戏法，只不过是更严格遵守编码指导（关闭的GOP，固定长度GOP，VC-1入口协议头，等等），这样就保证了同一视频在不同码率的文件之间帧完全对齐。这些WMV文件由一个后期处理工具被物理分成每两秒一个流控块的WMV文件。最后把这些流控块文件上传到CDN（内容分发网络）WEB服务器上，做了一个可以下载和顺序播放这些流控块的SILVERLIGHT播放器。

　　通过这个实现，NBC和微软提供了一个比WMS流控更好的用户体验，而这个仅仅是使用了简单的HTTP下载，从而提高了平均内容观看时间，也直接提高了转化成更多的广告和转化成货币的机会。

　　然而，内容分发网络(CDN)运营商也浪费了很多时间来管理系统里那些成百万的小文件。想像一下：如果每2秒钟的视频分成了不同的文件，而且每个媒体要重复成5个不同码率，算一下就知道了，一分钟的视频都生成了150个文件。一个90分钟的足球赛就有13500个文件！

　　尽管NBC奥运会转播对SILVERLIGHT和基于HTTP的自适应流是巨大的成功，很快，要求改进文件管理以及一些基本设计之后，把这个方案做成产品的需要就很明显了。

　　（待续）

通信人家园 (https://www.txrjy.com/)