CN103974147A - 一种基于mpeg-dash协议的带有码率切换控制和静态摘要技术的在线视频播控系统 - Google Patents

Abstract

本申请公开了一种基于MPEG-DASH协议的带有码率切换控制和静态摘要技术的在线视频播控系统，其中，客户端向流媒体服务器请求发送目标视频，流媒体服务器在接收到客户端的请求之后，向客户端发送目标视频的摘要MPD文件、以及目标视频的视频片段MPD文件，客户端从流媒体服务器下载并解析摘要MPD文件，得到目标视频的摘要画面、以及摘要画面在目标视频中的位置，在客户端上显示摘要画面，并由用户选择其中的一个摘要画面，客户端记录选择的结果，客户端从流媒体服务器下载并解析视频片段MPD文件，得到目标视频的视频片段的播放信息，客户端根据播放信息、以及选择的结果，确定与所选摘要画面对应的视频片段，向流媒体服务器请求从该视频片段开始发送并播放目标视频。

Description

一种基于MPEG-DASH协议的带有码率切换控制和静态摘要技术的在线视频播控系统

技术领域

本发明涉及互联网流媒体领域，更具体地，涉及基于Dash协议的带码率切换控制和静态摘要技术的播控系统。

背景技术

MPEG-DASH协议标准

目前，市场上主流的媒体传输规范包括微软集团的Smooth Streaming、Adobe集团的HDS、以及苹果集团的HLS等，这些规范都自成一家，没有通用性。MPEG-DASH协议是为了解决不同平台下HTTP协议的通用性而产生的。这一协议在2011年由MPEG组织批准，之后它就成为流媒体领域的一个热门话题，这一协议可以让不同的服务器和客户端之间进行交互，如果能够得到发展，势必会让流媒体领域发生重大变革。MPEG-DASH规范的产生是流媒体视频自适应码率传输不断走向成熟的至关重要的一步。在标准规范完成之后，DASH最重要的问题就是要有支持这一规范的实际产品，现存的一些技术可以为实现这些产品提供支撑，在DASH实现之后，不同平台开发的客户端和服务器之间就可以协同工作。

MPEG-DASH协议是基于HTTP协议实现的，HTTP流有很多优点。首先，因特网基础结构进化了，可以很好的支持HTTP协议。比如，CDN网络提供局部边缘高速缓存，可以减少数据的长距离传输。另外，HTTP协议对防火墙友好，几乎所有的防火墙配置都支持HTTP的外向连接。HTTP服务器技术很常见，因此为数百万用户提供HTTP流支持很划算。第二，使用HTTP 流，客户端可以不用在服务器上维持会话状态。因此，支持多用户除了HTTP的标准应用外不会为服务器增加额外费用，而且CDN可以使用标准HTTP优化技术来管理它。

在MPEG-DASH协议中，媒体内容被捕获和存储在HTTP服务器中，使用HTTP协议进行传输。这些媒体信息在服务器上存在于两个部分：一个是MPD（媒体表现描述，Media Presentation Description），描述了媒体文件可用内容的manifest、可提供的选择、URL地址和其它特征；另外一个部分是片段（segment），它是以块（chunk）方式存储的单一或多个文件中的实际媒体比特流，如图1所示。

在播放内容之前，DASH客户端首先得到MPD文件，MPD文件是一个XML文件，其格式如图2所示。MPD可以用HTTP、email、指状存储器、广播或其它方式进行传输。通过解析MPD文件，DASH客户端得到程序事件、媒体信息可用性、媒体类型、解决方法、最大和最小带宽和媒体分量的不同编码选择、可访问性特点和需要的DRM（数字权限管理，digital rights management）、媒体内容在网络上的位置和其它媒体特点。有了这些信息，DASH客户端就可以选择合适的编码方式，客户端使用HTTP GET向服务器请求获取片段。在缓存之后可以适应网络的不同吞吐量变化进行播放，客户端继续获取随后的片段，并且监视网络的带宽波动，通过监视和测量结果，客户端通过获取不同方案的片段来保证足够的缓存，从而适应不同的带宽。

MPD包含一个或多个周期。一个周期是指媒体文件时间轴上的一个时间集合。每一个时间集合都有一个起始时间和持续时间，包含一个或多个适应集（adaptation set）。每个adaptation set提供一个或多个媒体分量和它的多种编码选择的信息。例如，一个adaptation set可能包含同一媒体内容不同比特率的视频分量，另一个adaption set可能包含同一媒体内容不同比特率的音频分量(比如，低质量立体声和高质量环绕声)，每一个adaptation set通常包含多个描述。

一个表现（Representation）包含同一媒体分量的在不同编码方式下的片段，与其他表现在比特率、解决方案、通道数或者其他特征方面不同。每一 个表现由一个或多个片段组成，片段是时间序列中的媒体流块（chunk）。每个片段有一个URI，它是服务器上可寻址的地址，可以用HTTP GET或者带比特范围的HTTP GET来下载。

为了使用这种数据模型，DASH客户端首先解析MPD的XML文件，客户端根据MPD中的描述性元素来选择它需要使用的描述，描述性元素包括客户端容量和用户的选择。然后客户端建立时间线，开始播放所需要的正确的媒体分量。每个特征的表述包括有关当前片段的信息，这样可以使每个分段都用HTTP URI和比特范围来进行表述。对于实时描述，MPD提供片段的起始时间、结束时间、大概起始时间和片段的不同持续时间。

在DASH协议中，媒体内容可以作为一群片段来获得。一个片段作为DASH客户端HTTP GET或者部分HTTP GET的实体回应，媒体内容以成组的片段被编码和分离。第一个片段是包含初始化DASH客户端解码器所需信息的一个初始化片段，并不包含任何实际的媒体数据。

然后媒体流被分成一个或者多个连贯的媒体片段，每一个片段被分配一个URL、一个索引和明确的或者内在的起始时间和持续时间。

为了能够下载媒体片段，这个规范定义了一种使用片段索引盒来标记片段的方法，这个片段索引盒标记持续时间和字节偏移，从而描述了片段的次片段和流接入点。DASH客户端可以通过索引信息，用部分HTTP GETS来索取次片段。片段的索引信息可以放在那个片段开头的单独的盒子里，或者在片段的众多索引盒子中进行传播。可以使用不同的传播方法，比如分层的、环链或混合法。这个技术可以避免在片段的开头增加一个很大的盒子，从而避免了可能存在的内在（固有）下载延迟。

MPEG-DASH为ISO底层媒体文件格式和MPEG-2传输系统定义容器格式。MPEG-DASH的解码器未知，可以支持复用或者未复用的编码内容。在MPEG-DASH中，每个adaptive set可以使用一个保护内容的描述符来描述支持的DRM计划。Adaptive set也可以用复用的内容保护计划，只要客户端识别至少一个，它就可以解码内容。

这个标准定义了五个明确的配置文件，每个都可以寻址一个不同类型的 应用程序。每一个配置文件都定义了一系列约束条件，将MPD和片段格式限制到整个标准的子集中。因此，一个DASH客户端的配置文件只需要符合所要求的特征即可，而不需要符合整个标准。一些配置文件被设计成使用可继承内容从而为非标准的解决方案提供折中路径。

一些其他的标准组织或联盟与MPEG合作，在他们的标准中引用MPEG-DASH协议。同时，一些行业正在提供基于MPEG-DASH的解决方案。一些开源的实现方法也在进行中。大家相信，之后两年将会是这个产业应用这个标准的重要时刻，包括媒体和服务提供者、平台提供者、软件供应商、CDN提供者和设备制造商，还有为因特网上建立媒体流之间相互协作系统的重要时刻。

DASH的目标是通过定义一个通用的分发格式来适应因特网上视频数据的急剧增长，在视频流式传输到他们的设备时为终端用户提供最佳的视频体验及动态自适应变化的网络条件。它采用专有自适应流媒体解决方案的所有最佳元素，解决用户流式传输视频时遇到的传统问题。

MP4封装格式

媒体封装格式的实质是为与视频有关的数据提供一个存放的容器。MP4是一种常见的容器格式，它定义了通用媒体文件结构标准（参见参考文献[1]，Thomas W.Gary S.Gisle B Overview of the H.264/AVC Video Coding Standard2003，为了避免使本发明的描述限于冗繁，将该参考文献通过引用的方式合并于此），理论上讲可以在MP4文件中嵌入任何形式的数据。MP4是由很多个box（盒）组成的，box可以互相嵌套，大的box中嵌套小的box，一级一级地存放媒体数据。

MP4的box具有相同的结构，每个box都包含头部和数据域（数据字段）两部分，在头部中存放着整个box的类型和长度信息，box的类型表明了在当前box中会存放音视频的哪些信息，box的长度指明了当前box在文件中占用的字节数，当box的长度为0时代表这是文件的最后一个box，当长度为1时说明这个box真正的大小需要在另外的地方得到；数据域存放box的实际 数据，具体存放的数据由box的类型决定。

MP4文件的box可以由数据组成，也可以嵌套别的子box，结构非常灵活。MP4容器格式几乎可以描述所有的媒体结构，在苹果的IOS平台下只支持MP4格式的文件，在Android平台下对MP4的支持也非常成熟。在MP4文件中，媒体描述和媒体数据并不是放在一起的，而是分开的两个部分，在组织MP4结构的时候，可以通过索引来引用其他文件。

码率切换算法

DASH中同一视频内容可以有多种码率，同一码率的视频内容是由若干个内容上不重复的片段文件组成，因此实际播放时客户端可以根据网络状况动态选择不同码率的片段文件。

研究码率切换的目的就是为观众提供播放质量保障：

1.尽量减少时延、提高平均码率和避免播放停顿；

2.保证码率切换的平滑性，避免出现码率切换幅度过大的问题。

综合而言，影响码率切换的因素主要有网络状况和现有的缓冲时间长度。

Android平台视频的无缝播放(Seamless Playback)

现阶段Android平台并没有一个主流的无缝播放的解决方案，无缝播放的意义，就是一个视频片段到另一个视频片段的播放切换可以完美衔接，没有黑屏，卡顿、跳帧等现象。

现在，MPEG-DASH在PC平台上的实现正处于测试阶段，有各大公司都在致力于实现MPEG-DASH协议，DASH的消息交互主要发生在客户端和存放好了准备好的媒体内容的DASH服务器之间。DASH客户端和服务器间的简单交互流程如下所述。首先在建立TCP连接后，DASH客户端向服务器发送HTTP GET MPD请求，请求消息中包含了MPD文件的URL信息。服务器收到MPD请求后向客户端发送TCP数据包形式的MPD文件内容。随后客户端解析MPD文件中的媒体特征信息，包括获得媒体持续时间、比特率、URL地址等等。客户端向服务器请求媒体片段1，请求消息中包含所请求的 媒体片段的比特率、URL等参数。服务器收到媒体片段请求后将对应的媒体片段打包发送至客户端。客户端接收到开始播放媒体内容，同时客户端还启动自适应机制，在估计可用网络带宽后调整下一请求的媒体片段2的比特率，向服务器请求下一个媒体片段2。服务器给客户端发送相应比特率的媒体片段数据。当客户端暂停或停止播放时，客户端和服务器间停止交互消息，底层TCP连接断开，整个DASH过程就完成了。

摘要封装方法

视频摘要用来从视频数据中快速查找用户感兴趣的内容，对于在线视频播放来说有着很大的应用意义。现有的摘要封装方法是动态摘要封装方法，动态摘要的实质是一段动态视频，根据需要的不同可以是视频剪辑、缩略视频等。视频剪辑的主要目的是将用户最感兴趣的部分截取出来；缩略视频是通过一些视频片段序列的组合或者简单的视频帧的组合使用户对视频的内容有大致的了解。视频剪辑有很强的主观性，所以一般的视频摘要都是以缩略视频的方式进行动态摘要的显示。缩略图摘要的实现方式是通过抽样的方法提取整个视频中的关键信息，组成一个缩短的视频，这种方式可以让用户快速浏览整个视频，但是可能会有信息的损失。

现有的具有视频摘要的多媒体系统是基于动态摘要的方法实现的，因此摘要box（摘要盒）的设计是为动态摘要服务的，原有系统的视频摘要信息按图12所示方式存储，摘要box的类型是一种自定义的类型“kfra”，这个box由两个子box组成，第一个是“kfhd”，这个box用来存放“kfra”的基本信息，包括版本、标志、创建时间、修改时间、保留字节以及宽高等字段，其中版本（version）占3个字节，标志（flag）占1个字节，其余每个字段分别占用4个字节，整个“kfhd”占用32字节；另外一个是“kftk”，这个box中存放的是关键帧数目、以及每一个关键帧所在track（轨道）的音视频索引。entry table（条目表）的每个表项会存储一个24字节的AVIndexEntry结构体，这个结构体包含的信息是视频数据在文件中的偏移量，entry table的总大小为sizeof（AVIndexEntry）*关键帧数目。

动态摘要的封装是将关键帧信息写入MP4文件，具体操作过程是：根据一定的摘要提取算法得到关键帧的数目和每一个关键帧在视频文件中的偏移量；打开MP4文件，将操作指针移到文件的末尾，在文件的末尾写入box的类型、box中所包含的数据，然后计算box的总大小并写入size（大小）字段。

解封装过程是在服务器端实现的，首先寻找类型为“kfra”的box，如果没有找到，则表明这个视频文件不含关键帧信息；如果找到了，从“kfhd”中解析得到视频的宽高信息，保存下来，再从“kftk”中得到关键帧的数目，并从MP4文件中提取出相应的音视频数据，打包之后发送到客户端，客户端通过相应的视频模块进行解码播放。

动态摘要的本质是一个缩短的视频，因此，客户端在播放的时候顺次播放摘要视频的每一帧图像，用户无法与之进行交互。此外，动态摘要中封装的是未经解码的视频裸数据，因此，只有支持MP4格式的解码器才可以解析动态摘要文件，灵活性低。

基于缓冲等级的码率切换算法

基于缓冲等级的码率切换算法是Christopher Müller、Stefan Lederer和Christian Timmerer提出的，算法考虑到缓冲区的时长这一因素，如果缓冲时间比较充足，即使网络速率不是很高，也可以选择相对比较大的码率片段文件下载。虽然此时会导致下载文件片的时长超过其播放时长，但是由于缓冲区的时间足够，不易造成播放停顿现象。该算法中的网络带宽也是以上一个文件片的下载速率为参考值。

当缓冲区时间比较小时，选择一个比较小的码率，缓冲区时间在一定范围内时不做码流切换。具体算法如公式所示：

$\max \mathrm{bw}\left(s_i\right)=\left\{\begin{array}{cc}\mathrm{bw}\left(s_{i-1}\right)*0.3& 0\&le;{\mathrm{bl}}_i<0.15\\ \mathrm{bw}\left(s_{i-1}\right)*0.5& 0.15\&le;{\mathrm{bl}}_i<0.35\\ \mathrm{bw}\left(s_{i-1}\right)& 0.35\&le;{\mathrm{bl}}_i<0.50\\ \mathrm{bw}\left(s_{i-1}\right)*(1+b{l}_i*0.5)& 0.50\&le;{\mathrm{bl}}_i\&le;1\end{array}\right.$

maxbw(s_i)表示算法选择的第i片段的最大可选码率，i代表片段文件的序号，bw(s_i-1)是第i-1个片段文件的实际下载速率，bl_i是当前缓冲区时长与最大缓冲时长的比值。

这种算法根据上个片段的下载速率和当前的缓冲等级来选择即将下载的片段的码率。其中，当缓冲比值小于0.15时，系数选取0.3，选取上个片段下载速率的0.3倍的码率，这样有利于迅速提高缓冲区时长，避免出现播放停顿。

这种算法考虑到缓冲区时长比较高时、可以在网络状态比较低时选择较高码率的片段文件下载，这样有助于提高下载片段文件的平均码率。

这种算法在缓冲区设置比较大时效果比较好，但是直播时，缓冲区过大会造成直播时延过大，在直播中时延这个指标非常重要，这种牺牲时延的做法是不理想的。但是，在缓冲区设置较小的情况下，这种算法的缺点就十分明显，由于它是能够允许选择比最大网络下载速率（由带宽限制）高的码率，在实际应用中，这种方式并不令人满意：首先，最理想的码率切换算法就是在尽量提高码率的情况下，使片段下载时间等于片段的播放时长，该算法有时会允许选择过高码率，易造成下载时间比播放时长大许多，造成播放缓冲区明显减小（甚至耗尽造成播放中止）；其次，由于下载是以片段为单位的，如果缓冲区设置过小，一个片段文件的下载时间会引起缓冲区的等级变化过大大，致使下一个片段码率选择过小，进而造成码流切换幅度过大。

这种算法还有一个缺点，在实现中，码率的值是不连续的，视频提供商只能提供有限多个不同码率内容。这种算法将缓冲分为四个等级，若码率种类过少，会严重影响码率切换的决策及效果，这种算法需要码率种类相对比较多，这样就增加了视频内容提供商的成本和服务器端的存储负担。

Android平台音频/视频的无缝切换播放

Android平台音频/视频的无缝切换播放没有自己的底层解决方案，目前主流的方法是在一个布局上放置两个显示控件，例如视频播放用的SurfaceView控件(此处设为A和B)，分别对应两个播放方法实例（例如android自带的Mediaplayer），首先隐藏SurfaceView B，只显示surfaceView A，在播放 的时候surfaceView B先加载将要播放的视频B，等到视频A播放完毕后，切换surfaceView A和B的显示并播放。由于切换控件显示比切换视频源更快，所以用户感觉不出来切换了显示控件，以达到无缝切换播放的目的。

在一个布局上放置2个（或更多个）显示控件在不同平台上可能会引起不可控的问题，同时为了两个显示控件创建的2个（或更多个）播放方法的实例（前文提到的mediaplayer）也会浪费大量的内存，增加程序崩溃的可能性，同时，从视频编解码的原理来看，这并不是真正的无缝切换播放技术。

发明内容

本申请的发明人考虑到现有技术的上述情况而作出了本发明。

本发明要解决的技术问题主要包括：

(1)从工程上实现MPEG-DASH协议；

(2)完善DASH协议的技术细节；

(3)在Android移动平台下搭建此多媒体架构（可在手机，平板等移动设备上观看MPEG-DASH协议的视频）；

(4)对视频摘要进静态封装。包括摘要box设计、摘要信息的封装、摘要信息的解封装三部分；

(5)为DASH协议提出了一种改进的码率切换算法；

(6)为实现Android平台的无缝播放提供了一种解决方案。

根据本发明的实施例，提供了一种基于MPEG-DASH协议的带有码率切换控制和静态摘要技术的在线视频播控系统，其包括流媒体服务器、以及客户端，所述流媒体服务器和所述客户端以可通信方式连接，所述客户端用来向所述流媒体服务器请求发送目标视频，并在所述客户端本地播放所述目标视频，其中，所述客户端包括摘要MPD下载及解析模块、摘要显示和选择模块、视频片段MPD下载及解析模块、以及视频播放模块，所述流媒体服务器包括MPD发送模块，所述MPD发送模块用来在所述流媒体服务器接收到所述客户端的所述请求之后，向所述客户端发送所述目标视频的摘要MPD文件、以及所述目标视频的视频片段MPD文件，所述摘要MPD下载及解析模块用 来从所述流媒体服务器下载并解析所述摘要MPD文件，得到所述目标视频的摘要画面、以及所述摘要画面在所述目标视频中的位置，所述摘要显示和选择模块用来在所述客户端上显示所述摘要画面，并由用户选择其中的一个摘要画面，并向所述视频播放模块通知所述选择的结果，所述视频片段MPD下载及解析模块用来从所述流媒体服务器下载并解析所述视频片段MPD文件，得到所述目标视频的视频片段的播放信息，并将所述播放信息传送到所述视频播放模块，所述视频播放模块用来根据所述播放信息、以及所述选择的结果，确定与所选摘要画面对应的视频片段，向所述流媒体服务器请求从该视频片段开始发送并播放所述目标视频。

根据本发明的实施例，提供了一种基于MPEG-DASH协议的带有码率切换控制和静态摘要技术的在线视频播控方法，其用于包括流媒体服务器、以及客户端的在线视频播控系统，所述流媒体服务器和所述客户端以可通信方式连接，所述在线视频播控方法包括：步骤1，所述客户端向所述流媒体服务器请求发送目标视频；步骤2，所述流媒体服务器在接收到所述客户端的所述请求之后，向所述客户端发送所述目标视频的摘要MPD文件、以及所述目标视频的视频片段MPD文件，步骤3，所述客户端从所述流媒体服务器下载并解析所述摘要MPD文件，得到所述目标视频的摘要画面、以及所述摘要画面在所述目标视频中的位置，步骤4，在所述客户端上显示所述摘要画面，并由用户选择其中的一个摘要画面，所述客户端记录所述选择的结果，步骤5，所述客户端从所述流媒体服务器下载并解析所述视频片段MPD文件，得到所述目标视频的视频片段的播放信息，步骤6，所述客户端根据所述播放信息、以及所述选择的结果，确定与所选摘要画面对应的视频片段，向所述流媒体服务器请求从该视频片段开始发送并播放所述目标视频。

本发明的有益效果主要体现在以下方面：本发明基于视频文件分片，从工程上实现了Android平台下的MPEG-DASH协议，系统和功能比现存的实现方式更加完整，具有很强的实用性。在MPEG-DASH播控系统中还融入了新的静态视频摘要封装技术，使客户端（手机）能够通过静态视频摘要快速选择感兴趣的视频片段，并使服务端对相应的视频片段数据进行快速定位并 发送给客户端，从而提高手机用户观看视频的用户体验。

附图说明

图1是基于MPEG-DASH协议的系统架构示意图；

图2是MPD文件的结构示意图；

图3-5是根据本发明的实施例的支持MPEG-DASH协议的多媒体系统的架构示意图；

图6-7是根据本发明的实施例的MPD文件的结构示意图；

图8是根据本发明的实施例的规范命名方法的示意图；

图9是根据本发明的实施例的在线视频播控系统的视频播放模块的操作流程图；

图10是根据本发明的实施例的摘要信息封装的操作流程图；

图11是根据本发明的实施例的摘要信息解封装的操作流程图；以及

图12是示出MP4文件格式的示意图。

具体实施方式

首先简述基于DASH协议的视频播控的原理。

基于DASH协议的视频分发系统由客户端和DASH流媒体服务器（视频分发服务器）两部分组成。DASH服务器端将视频摘要信息（关键帧）从视频文件中解析出来，以图片文件的方式存放在服务器上。客户端向服务器请求发送视频之后，DASH服务器首先传送摘要MPD文件，客户端解析MPD文件之后获得摘要画面（关键帧画面）的网络地址以及摘要画面所对应的视频文件中的位置，在客户端显示摘要画面、并选中某个摘要画面之后，客户端会再次向服务器请求发送视频，服务器传送视频MPD文件，并根据客户端发送的请求中的信息（选中的摘要画面所对应的视频片段的位置）发送特定的视频片段（以及之后的视频部分），供客户端播放。对于DASH服务器发送给客户端的信息，客户端可以对服务器发送的视频MPD文件进行解析并获得用户需要的信息。

下面简要说明本发明的设计思想。

(1)设计实现摘要及视频MPD文件：

MPD文件中存放了关于流媒体文件基本格式的内容，描述了可用内容的URL地址和其它特征，还有视频片段列表，以及存储单一或多重文件中的实际多媒体比特流。MPD基于XML语言，通过不同的标签标识不同的信息，在本系统中一共设计了两个MPD文件，一个用来存放摘要信息，另外一个用来存放视频片段信息。

(2)设计实现多媒体片段及摘要画面封装及解封装：

DASH系统中的多媒体内容是作为片段存储在DASH服务器上的，整个媒体流就是一个连续的片段群，每一个片段可以作为HTTP GET的实体回应，每一个片段被单独编码、分离和解码。每一个片段的开头都是一个流接入点，解码器可以对每一个片段进行单独解码。在本系统中，例如，每个视频文件都被分成5秒的片段，并被独立编码成MP4文件，在客户端，通过连续HTTPGET请求来获得从某个视频摘要标识的位置开始的MP4文件，并对其后的片段进行解码播放，而略过这个接入点之前的文件，从而实现播放视频某一部分内容，从而节省网络流量。摘要信息是一幅或多幅画面，这些画面被封装在DASH流媒体文件中，在服务器端通过解析模块解析之后存放于服务器上。所有的媒体片段、MPD文件、以及摘要画面都放在服务器的某一个文件夹中，通过固定的服务器地址进行访问。

(3)DASH客户端框架的设计与实现：

在客户端与DASH服务器进行交互时，例如，在传递视频地址就会在视频地址前添加“DASH//”标签，系统在检测到有DASH标签时会去服务器获取摘要画面并显示摘要，如果没有检测到该标签，则按照普通视频播放的方法来播放视频。这样，系统可以自动识别需要使用的播放协议。

支持MPEG-DASH协议的多媒体系统主要由规范命名模块、MPD生成模块、摘要MPD下载及解析模块、摘要显示和选择模块、视频片段MPD下载及解析模块、视频播放模块组成，其中，前两个模块位于服务器，后四个模块位于客户端。规范命名模块用来对输入的视频文件（视频片段）进行标 准化命名。当文件名符合规范之后，MPD生成模块生成摘要MPD及视频片段MPD文件。之后，服务器上就存在两个MPD文件、若干个视频片段以及摘要画面，摘要画面是事先提取的，能体现视频内容的图片。DASH客户端在播放视频文件之前，会先调用摘要MPD下载及解析模块，从服务器上获得摘要MPD文件，并进行解析，得到摘要画面，通过摘要显示模块展示给用户。用户浏览摘要文件，通过点击来选中感兴趣的部分，视频片段MPD下载及解析模块用来下载视频片段MPD文件，并解析得到视频片段列表，视频播放模块用来进行视频播放。整个多媒体系统的消息传递架构如图3所示、系统结构如图4所示、模块调用关系如图5所示。

(4)对摘要box进行设计：

MP4文件的所有信息都是封装在box中的，一个MP4文件就是由很多box组成的。这些box有不同的类型和长度，但是有固定的定义格式，每个box的头部包括两个信息：这个box包含头部在内的大小和这个box的类型，头部之外便是这个box的具体数据（body），每个box的body部分会根据box的类型不同存放不同的数据。本发明可采用两种添加box的方法，一种是修改已有box，将原MP4文件中在解码时会忽略的free box有效利用起来用来存放我们的摘要信息，另一种方法是设计一个独立的box，并将这个新的box添加到文件中。为了符合MP4文件数据封装标准的要求并且使用户搜索或使用视频文件时更加高效简便，优选将视频摘要整合为一个新的box并封装到原视频文件中。

(5)对摘要信息进行封装：

动态摘要和静态摘要封装的目的都是将设计好的box结构封装到原MP4文件中，整个过程分为读取文件、插入位置定位、以及写入摘要信息三个部分。对于动态摘要封装方式，封装到文件中的是每一帧摘要信息在文件中的偏移位置，对于静态摘要封装方式，封装到文件中的是每一帧摘要信息的静态画面文件。在获得文件操作指针之后，将指针移到文件末尾，按照我们设计好的box格式将摘要信息写入MP4文件中。

(6)对封装好的信息进行解封装：

在完成摘要box的封装工作后，在客户端需要将这些摘要信息显示给用户，所以就需要完成它的逆过程，即从封装入文件的摘要box中将摘要画面（或视频）提取并显示出来。对于动态摘要封装方式，通过解析可以得到摘要数目以及每一个摘要样本（sample）在原文件中的偏移位置；对于静态摘要封装方式，通过解析可以得到静态摘要画面文件。

(7)提出了一种改进的码率切换算法：

本申请提出了一种改进的码率切换算法，这种算法是基于片段下载速率的码率切换算法：在下载文件片时计算文件片的大小和下载耗时，计算得出该文件片的下载速率作为下一个文件片的码率选择的参考。在实际计算中，文件片的下载耗时包含两个部分：实际网络数据传输耗时和客户端处理耗时。从客户端接收数据完毕到开始决策下片的码率之间需要将数据写入磁盘，然后执行此处至决策码率的代码，这之间也有一定得耗时。这一段时间耗时也是不确定的，跟操作系统当时的运行状态有关。

(8)提供了一种Android平台上无缝播放的解决方案：

利用MediaExtractor拉取视频文件的文件头，获得视频格式，码率，宽度，高度，帧率，颜色格式等等信息，用这些信息设置MediaCodec，然后通过MediaExtractor不断拉取视频内容，在下一个视频到来的时候，可以直接跳过读取文件头的步骤，拉取第二个视频的内容，“填充”到第一个视频的后面，这样就实现了视频的无缝播放。

下面，结合附图对技术方案的实施作进一步的详细描述。

如图3所示，一个基于DASH协议的视频分发系统由一个视频分发服务器和客户端组成（作为对照，也示出了客户端与普通视频服务器的交互关系），服务器负责响应客户端的MPD请求和媒体片段请求、向客户端发送MPD文件和视频片段，客户端负责解析MPD文件和下载并播放视频片段，同时监控流量状况决定视频码率的选择。视频分发服务器主要包括规范命名模块、MPD生成模块、客户端主要包括摘要MPD下载及解析模块、摘要显示和选择模块、视频片段MPD下载及解析模块、视频播放模块。本领域的技术人员应当理解，图3、4和5中示出的系统框图仅为用来说明本发明的原理的示意，其中的各 个功能模块并非完整和对应的表示，不构成对本发明的限制。本发明的实施例可按照实际应用而添加/省略各个功能模块。

首先，说明摘要MPD文件和视频MPD文件的格式。

摘要MPD文件（命名方式为[filename]_abstract.mpd）文件包含关于视频摘要的多媒体信息，可包含三层标签：第一层为<MPD></MPD>，其中包含MPD的命名空间，最小缓存时间(以秒为单位)，视频流类型(是静态流还是动态流)以及MPD配置文件空间；第二层为KeyframeList标签，包含关键帧（摘要画面）的个数（数量）信息；第三层为Keyframe标签，包含每个关键帧画面的网络URL、对应原视频中的时间偏移量、以及字节偏移量。包含摘要的MPD文件格式如图6所示。摘要是为了给用户提供一个视频内容概览，关键帧是指摘要的内容，也就是摘要画面，来自于视频内容。

其中，KeyFrameNum为视频文件的关键帧个数，KeyFrameURL为关键帧的网络地址，KeyFrameTime为关键帧在视频文件中的时间位置，KeyFramePosition为关键帧在视频文件中的字节偏移量。

视频片段MPD文件的命名方式可为fileName.mpd，其中包含四层标签，第一层为<MPD></MPD>，其中包含MPD的命名空间、最小缓存时间(以秒为单位)、视频流类型（是静态流还是动态流）以及MPD配置文件空间；MPD标签下会包含一个或多个AdaptationSet标签（第二层），每个AdaptationSet里包含同一个视频的不同媒体分量（可能是视频流、音频流或者字幕信息）和多重编码选择信息。每个AdaptationSet里又会包含一个或多个Representation标签（第三层），每个Representation里包含媒体的一个描述，这个描述由一个或多个片段组成，片段是时间序列中的媒体流块（chunk），为了对这些媒体流进行定位，每个片段都会有一个URI（URL），这个URI是服务器上可寻址的地址。

通过HTTP-GET命令，客户端可以从服务器上下载该MPD文件并解析，之后就可以从URI所指向的地址上获得视频的每一个片段进行播放。。

在Segment标签描述每一个视频片段的内容（每个视频片段各有一对Segment标签）。对于视频片段的起始点，本申请定义了两种定位方法，一种 是按视频片段在视频中的时间偏移量进行定位，另一种是按视频片段在视频中的字节偏移量进行定位。此外，在Segment标签中同时也包含每一个片段的持续时间。

具有一对AdaptationSet和一对Period标签的结构如图7所示。

接下来，说明服务器的主要模块的功能和实现。

(1)规范命名模块

规范命名模块负责对视频文件进行规范命名。由于在MPD文件中，所有的文件都是通过URI索引获得的，同时在获取到MPD文件之后对MPD文件进行解析，统一的命名可以有效提高MPD生成和解析以及视频片段的连续播放效率。

现存的DASH系统并没有一个统一的命名方式，在实现的过程每个系统都有各自的默认的规定，但是并没有将这个规定统一起来。作为示例，为了便于说明本发明的原理，在本说明书中提供了具体的规范命名方法，然而，本领域的技术人员应当理解，本发明可同样应用于其它适当的命名方式。

规范命名模块统一视频片段的文件名，所有的MP4视频片段都以fileName开头，按时间顺序连接视频序号“_001”，“_002”……，依次类推。所有的视频摘要文件也以fileName开头，连接摘要在视频中的时间偏移量“[00_00_04]”，“[00_00_19]”……（时间偏移量是事先提取的），其中前两位是小时，中间两位是分钟，最后两位是秒。在解析摘要在视频中的偏移量的时候都换算成秒。

输入文件路径，列出此路径下的所有文件，对每个文件分别进行操作，首先判断该文件是否是视频文件，如果是，就将此文件命名为文件名+“_”+“分片序号”这样的格式；如果不是视频文件继续判断它是不是画面文件，如果是静态画面文件就将它命名为文件名+“[”+画面时间+“]”的格式，画面时间的格式为“时_分_秒”，各占两位；如果既不是视频文件也不是画面文件，则判断它是不是mpd文件，mpd文件的命名就是“文件名”+“.mpd”或“文件名”+“_abstract”+“.mpd”。对于不是以上三种格式的文件不做操作。上述过程如图8所示。

(2)MPD生成模块

流媒体文件在经过一定的视频摘要方法（例如，关键帧提取算法，关键帧是从视频中抽取的一些静态图像用于表示镜头的内容以此实现视频内容的快速浏览并能够与视频索引技术等相结合进行基于内容的视频检索与分析。）之后输出摘要画面，画面信息中包含了它在视频中的偏移量，将视频的所有分片和摘要画面都放到流媒体服务器上以视频文件名命名的文件夹里，MPD生成模块根据视频媒体信息，例如编码方式、高度、宽度、片段时间，码率等信息，生成对应的视频MPD文件和摘要MPD文件，并与视频分片文件放在同一文件夹下供客户端进行请求访问。生成MPD文件的过程就是不断将前述MPD包含的信息写入文件的过程，每个MPD都是由上述一系列标签组成，在解析的过程中需要分析这些标签并得到需要的结果。

接下来，说明客户端的主要模块的功能和实现。

(1)摘要MPD下载及解析模块

客户端在下载摘要MPD文件之前可以选择是否缓存MPD以及是以时间偏移量还是字节偏移量进行定位（默认为不进行缓存、按时间偏移量进行定位）。在下载了摘要MPD文件之后，在摘要MPD文件中查找以KeyFrameList开头的标签，这个标签下首先将KeyFrameNum解析出来，新建两个KeyFrameNum长度的链表KeyFrameUrlList和KeyFrameDiffList，前者存放每一关键帧的HTTP地址（URL），后者存放每一关键帧对应的偏移量信息，以ByteDiff标签存放，如果是按时间偏移量定位的话就存放时间信息，如果按照字节偏移量进行定位的话就存放字节偏移量。每个摘要画面的URI从KeyFrameURL标签之后第二个字符开始，到KeyFrameTime标签之前第二个字符止，时间偏移量取KeyFrameTime标签之后的内容，字节偏移量取ByteDiff标签的内容，将解析出来的信息保存到KeyFrameInfo结构中，这个结构包括KeyFrameNum（关键帧数目）、KeyFrameUrlList和KeyFrameDiffList这些信息将作为摘要显示和选择模块的输入参数。简而言之，摘要MPD下载及解析模块的操作可以概括为：首先从服务器获取MPD文件，客户端可以选择是否缓存本MPD文件，如果缓存，就将此文件保存到本地；然后将MPD文件读出 并进行解析，根据特定的标签，解析得到关键帧的数目，即KeyFrameNum和每个关键帧画面对应的URL和在原视频文件中的偏移量。用户可以选择按照时间偏移量或字节偏移量来对关键帧进行定位，最终返回一个KeyFrameInfo的结构，这个结构如下所示。

KeyFrameInfo：

int KeyframeNum//关键帧数目

List KeyFrameURL//关键帧网络地址

List KeFrameDiff//关键帧对应的时间

(2)摘要显示和选择模块

在摘要MPD文件解析完之后，摘要显示和选择模块继续进行处理，该模块的输入参数是在摘要MPD下载及解析模块解析出来的KeyFrameUrl链表和KeyFrameDiff链表，首先，调用客户端的MPD解析模块根据KeyFrameUrl链表和KeyFrameDiff链表中的信息，进行摘要画面（关键帧画面）文件下载，下载完成之后添加到显示控件里，更新UI，从而在客户端显示出来、并由客户进行选择（例如，通过点击摘要画面）。

在这个过程中，每个摘要画面的加载及显示都是独立的，如果某个摘要画面被破坏或者因为别的原因加载失败，并不会影响其它摘要画面的显示，在这种情况下，只是减少了一个或多个随机接入点，在用户单击某个ImageView（显示组件中的一个控件）的时候，就会从当前摘要画面对应的位置开始播放视频，达到只播放视频的某一部分的效果。

(3)视频片段MPD下载及解析模块

这里，服务器可向客户端发送含有全部视频片段信息的完整视频片段MPD文件，这样，客户端不需向服务器通知用户选择了哪个摘要画面，而是在本地通过在视频片段MPD文件中找到所选摘要画面相关的视频片段（例如，偏移量与所选摘要画面的偏移量最接近的视频片段的视频片段MPD文件）。

视频片段MPD文件下载过程可以与摘要MPD下载过程并行进行，或者如上所述，。这个MPD文件在被下载之后也作为字符串输入视频片段MPD下载及解析模块，视频片段MPD下载及解析模块首先从Representation标签 里的“mimeType”得到视频格式，“codecs”中得到该视频片段的编解码器类型，“width”中得到该视频片段的视频宽度，“height”中得到该视频片段的视频高度，“frameRate”中得到该视频片段的视频帧率。然后，在Segment标签下的“bandwidth”节点得到视频片段的比特率，在“SegmentURL”节点得到视频片段的HTTP地址（URL），StartTime标签里得到该视频片段在整个视频文件中的时间偏移量，在ByteDiff中得到该视频片段在整个视频文件中的字节偏移量。

(4)视频播放模块

视频播放模块的输入信息为视频片段MPD下载及解析模块解析出来的所有视频片段的URL地址、视频片段对应的时间或字节偏移量（以下简称视频偏移量）、以及从摘要显示模块传送的摘要文件（关键帧画面）在整个视频文件中的偏移量（以下简称摘要偏移量）。视频播放模块进行的视频播放过程如下所述。

首先，通过查找上述输入信息，找到偏移量距离用户所选的摘要画面的偏移量最接近的视频片段，在解析出来的视频片段链中找到这个视频片段的URL地址，客户端使用HTTP-GET命令，向服务器请求发送这个视频片段，并从这个片段开始播放其后的视频部分。在下载视频片段时，用户可以在客户端设置是否在本地缓存这个片段的参数（默认为不缓存），这样，用户可以把感兴趣的部分缓存在本地（客户端），下次播放的时候就会作为本地文件进行播放，不需要再次下载。本模块又由音视频解析子模块和音视频渲染子模块组成。

上述播放流程如图9所示。

在服务器上，多媒体文件是分片段存放的，例如每个片段为5秒，对于每个片段重复上述解码渲染过程就实现了整个视频的播放。

可选地，客户端也能够向服务器通知用户选择了哪个摘要画面，服务器可依此找到偏移量与用户所选的摘要画面的偏移量最接近的视频片段，并直接向客户端发送该视频片段。

下面说明本发明的实施例的dash播控系统所采用的码率自适应切换策略。

文件片的下载耗时包含两个部分：实际网络数据传输耗时和客户端处理耗时。从客户端接收数据完毕到开始决策下片的码率之间需要将数据写入磁盘，然后执行此处至决策码率的代码，这之间也有一定得耗时。这一段时间耗时也是不确定的，跟操作系统当时的运行状态有关。

第i个片段的下载过程中，都记录下载时间t_i和片段的大小L，则该片段的下载速率T_d(i)：

$T_d\left(i\right)=\frac{L}{t_i}$

在做码率切换决策的时候，若仅参照上片的下载速率，则在下载网络变化比较大时，码率切换比较频繁，切换幅度会比较大。

为了保证码率切换的平滑性，计算每个片段的下载速率，将前若干片段的下载速率作为下一个片段下载速率的参数，将每一个下载速率都给一个权值，以这些下载速率的权值和作为码率的选择。计算时，片段文件越多，历史网络状况对结果影响就越大，能够减少码率的切换次数，但是会造成对网络变化的灵敏度降低。作为示例，选取前两个片段的下载速率的来确定下一片段的码率，计算如公式所示。

$T_e\left(i\right)=\left\{\begin{array}{cc}{T}_{\min }& i=\mathrm{1,2}\\ \mathrm{\&alpha;}{T}_d(i-1)+(1-\mathrm{\&alpha;})T_d(i-2)& 0\&le;\mathrm{\&alpha;}\&le;1,i>2\end{array}\right.$

T_e(i)表示第i个片段码率的估计值，T_min代表可选的最小码率，T_d代表之前的片段的实际下载速率。α代表一个0和1之间的常数，可以由用户根据需要而设置。α越大（越接近1），算法对网络的灵敏度就越高（即，仅考虑前一片段的网络状况（实际下载速率）来确定当前片段的码率），这个值与0.5之差的绝对值越小，码率切换的平稳性越好（即，通过综合考虑前两个片段的网络状况来确定当前片段的码率）。

该算法的优点是计算简单，保留所有片段文件的下载速率。且该算法能 够十分迅速地根据网络的变化情况作出调整，因此该算法能够对网络速率变化响应比较高。同时由于在计算第i个片段时引入了第i-2个片段的下载速率，能够减少码率切换的幅度。

下面说明本发明的实施例的dash播控系统在应用于Android平台时所采用的无缝播放方案。

以下步骤是在Android视频播放客户端上进行的。

基于Android平台的完整的无缝播放模块主要用到了MediaExtractor、MediaCodec、Surface这三个类（控件）。MediaExtractor用来读取视频格式信息和拉取视频的数据信息，MediaCodec负责解码数据信息，并把解码后的数据送给Surface，Surface是一个显示控件，接收到解码信息后调用android的底层控件把每一帧渲染（render）到屏幕上，这就是一个完整的视频播放流程。

在上一个片段播放完毕需要在片段之间进行切换时，先清空当前解码器的的InputBuffer和OutputBuffer（输入和输出缓冲），在不改变视频的格式信息的基础上，把下一个视频片段的视频内容（Video）直接用解复用器（Extractor）送给解码器的InputBuffer（输入缓冲），这样处理实际就是利用DASH视频片段格式相同的特点，跳过对视频格式信息的重复处理，把视频片段的内容在本地无缝拼接起来。

由于MediaExtractor（解复用器）和MediaCodec（解码器）都是android自带的组件，对于不同版本的兼容性比其他方案更好，且MediaCodec支持硬解，速度和清晰度也比其他方案更好。

下面，举例说明视频摘要信息的封装和解封装方法。视频摘要信息封装可以看作一个视频的补充。这里，本领域的技术人员能够理解，对于通过任意现有和将来的摘要封装和解封装方法而生成的摘要信息，本发明都是适用的。

摘要的封装是将关键帧信息写入MP4文件，具体操作过程是：根据一定的摘要提取算法得到关键帧的数目和每一个关键帧在视频文件中的偏移量；打开MP4文件，将操作指针移到文件的末尾，在文件的末尾写入box的类型，box中所包含的数据，然后计算box的总大小并写入size字段。自创的用于 摘要信息封装的smof box结构的数据成员初始化如下：

int size=0;

BYTE type[4]={'s','m','o','f'};

BYTE version=NULL;

BYTE flags[3]={NULL};

BYTE*sm[num];

*sm[num]为box body部分用于存放摘要图像数据的box结构，其中num为视频文件的摘要画面个数，是由一定的摘要提取算法（例如关键帧提取算法）对特定的MP4文件提取出来的具有一定代表性的关键帧，MP4文件的时长越长，摘要画面数就相应越多。封装过程如图10所示。

经过对多个视频文件的测试，封装后的摘要信息约占视频文件的1%～2%，增加的这部分字节对文件传输存储等应用方面影响很小，并且本发明设计的封装格式符合MP4格式要求，对于不支持摘要显示的MP4文件解码器，这个摘要box是不能被识别为正常的box（因为在摘要box的头部中包含的这个box的大小信息不合法），解码器便会自动略过这个box所占的字节，继续解析后续的box，而在在本发明的系统中，会根据box的类型定位出摘要box，进而进行摘要信息的提取和解码。

正确写入摘要数据的视频文件与原文件相比会多出一个新的box数据部分，即smof box数据结构，Box包括header中的box属性参数以及body中的主要摘要数据。该box由于在设计与封装过程中遵循了标准的规定，因此在写入成功之后，这个box可以被MP4的解析器正确识别出来。

摘要信息解封装模块：

摘要数据的提取需要两个步骤，首先，从文件开始的四个字节提取出第一个box的类型，如果这个box不是smof box则在接下来四个字节中提取出当前box的大小信息，跳过相应的字节，继续分析下一个box，直到找到类型名为“smof”的box，获取到其在流媒体文件中的位置。根据本发明的box的设计方法，从所述位置的第12个字节之后为真正摘要数据存放的位置，自这个偏移量开始从box body中提取出摘要画面，并将其显示出来。下面具体 描述解封装的各个步骤。

首先要定位smof box。将box type作为定位依据，在整个MP4视频文件中查找“smof”字符串，返回其所在位置偏移量。根据上文所述smof box的结构特点便可以进一步推算到box size的存储位置，将之定位并提取出其中内容，即box所占空间大小的信息。在已提取出box位置偏移量、box大小的信息后，根据smof box结构便可计算出box body，即摘要画面数据所占空间大小以及存储位置偏移量，利用这两个参数将其提取出来。

将上述参数推算过程用式子表示可以更加简单明了：

box类型偏移量=box size位置偏移量+4；

下一个box位置偏移量=box size位置偏移量+box size大小；

关键帧数目偏移量=smof box type+32；

下一个关键帧数据偏移量=上一个关键帧偏移量+当前关键帧size

具体实现过程如图11所示。

首先读取每个box的size，然后读取box type，如果当前box不是smof box的话跳过box size大小的字节，继续下一个box的解析，如果当前box是smof box的话，解析得到version、flag、creation time、modification time、关键帧数目以及关键帧具体数据，获得了box size大小的二进制数据后，将其转换为整型数据。

最后利用上述提取与推算出的信息，将摘要画面数据从文件中提取出来并生成画面文件方便用户阅览。解析过程由服务器端完成，得到摘要画面之后会保存到服务器上，作为多媒体系统摘要显示的数据来源。

综上所述，本领域的技术人员能够理解，对本发明的上述实施例能够做出各种修改、变型、以及替换，其均落入如所附权利要求限定的本发明的保护范围。

Claims (12)

1.一种基于MPEG-DASH协议的带有码率切换控制和静态摘要技术的在线视频播控系统，其包括流媒体服务器、以及客户端，所述流媒体服务器和所述客户端以可通信方式连接，所述客户端用来向所述流媒体服务器请求发送目标视频，并在所述客户端本地播放所述目标视频，

其中，所述客户端包括摘要MPD下载及解析模块、摘要显示和选择模块、视频片段MPD下载及解析模块、以及视频播放模块，所述流媒体服务器包括MPD发送模块，

所述MPD发送模块用来在所述流媒体服务器接收到所述客户端的所述请求之后，向所述客户端发送所述目标视频的摘要MPD文件、以及所述目标视频的视频片段MPD文件，

所述摘要MPD下载及解析模块用来从所述流媒体服务器下载并解析所述摘要MPD文件，得到所述目标视频的摘要画面、以及所述摘要画面在所述目标视频中的位置，

所述摘要显示和选择模块用来在所述客户端上显示所述摘要画面，并由用户选择其中的一个摘要画面，并向所述视频播放模块通知所述选择的结果，

所述视频片段MPD下载及解析模块用来从所述流媒体服务器下载并解析所述视频片段MPD文件，得到所述目标视频的视频片段的播放信息，并将所述播放信息传送到所述视频播放模块，

所述视频播放模块用来根据所述播放信息、以及所述选择的结果，确定与所选摘要画面对应的视频片段，向所述流媒体服务器请求从该视频片段开始发送并播放所述目标视频。

2.根据权利要求1所述的基于MPEG-DASH协议的带有码率切换控制和静态摘要技术的在线视频播控系统，其中，所述摘要MPD下载及解析模块还用来：在从所述流媒体服务器下载所述摘要MPD文件之后，将所述摘要MPD文件存储在客户端本地之后进行解析，得到摘要画面的数目、每个摘要画面对应的网址、以及每个摘要画面在原视频文件中的位置，所述位置是时间位置或字节位置。

3.根据权利要求2所述的基于MPEG-DASH协议的带有码率切换控制和静态摘要技术的在线视频播控系统，其中，所述摘要显示和选择模块还用来：根据所述摘要MPD下载及解析模块得到的每个摘要画面对应的网址，将每个摘要画面显示在所述客户端的显示器上，所述客户端的用户通过点击所显示的某个摘要画面而选择该摘要画面。

4.根据权利要求3所述的基于MPEG-DASH协议的带有码率切换控制和静态摘要技术的在线视频播控系统，其中，所述视频片段MPD下载及解析模块还用来：从所述流媒体服务器下载所述视频片段MPD文件之后，将所述视频片段MPD文件存储在客户端本地之后进行解析，得到所述视频片段的播放信息，所述播放信息包括视频片段的视频格式、编解码器类型、宽度、高度、帧率、网址、视频片段在原视频文件中的位置，所述位置是时间位置或字节位置。

5.根据权利要求4所述的基于MPEG-DASH协议的带有码率切换控制和静态摘要技术的在线视频播控系统，其中，所述视频播放模块还用来：根据所述播放信息中的视频片段在原视频文件中的位置，找到距离所选摘要画面最近的视频片段，并向所述流媒体服务器请求从该视频片段开始发送并播放所述目标视频。

6.根据权利要求5所述的基于MPEG-DASH协议的带有码率切换控制和静态摘要技术的在线视频播控系统，其中，所述流媒体服务器还用来：在向所述客户端发送视频片段时，通过以下公式确定要发送的视频片段的码率：

$T_e\left(i\right)=\left\{\begin{array}{c}{T}_{\min },i=\mathrm{1,2}\\ \mathrm{\&alpha;}{T}_d(i-1)+(1-\mathrm{\&alpha;})T_d(i-2),i>2\end{array}\right.$

其中，T_e(i)表示即将发送的第i个片段的码率，i为正整数，T_min代表可选的最小发送码率，T_d(i-1)、T_d(i-2)分别为已经发送的第i-1和i-2个片段的实际发送速率，并且，0≤α≤1。

7.一种基于MPEG-DASH协议的带有码率切换控制和静态摘要技术的在线视频播控方法，其用于包括流媒体服务器、以及客户端的在线视频播控系统，所述流媒体服务器和所述客户端以可通信方式连接，

所述在线视频播控方法包括：

步骤1，所述客户端向所述流媒体服务器请求发送目标视频；

步骤2，所述流媒体服务器在接收到所述客户端的所述请求之后，向所述客户端发送所述目标视频的摘要MPD文件、以及所述目标视频的视频片段MPD文件；

步骤3，所述客户端从所述流媒体服务器下载并解析所述摘要MPD文件，得到所述目标视频的摘要画面、以及所述摘要画面在所述目标视频中的位置；

步骤4，在所述客户端上显示所述摘要画面，并由用户选择其中的一个摘要画面，所述客户端记录所述选择的结果；

步骤5，所述客户端从所述流媒体服务器下载并解析所述视频片段MPD文件，得到所述目标视频的视频片段的播放信息；以及

步骤6，所述客户端根据所述播放信息、以及所述选择的结果，确定与所选摘要画面对应的视频片段，向所述流媒体服务器请求从该视频片段开始发送并播放所述目标视频。

8.根据权利要求7所述的基于MPEG-DASH协议的带有码率切换控制和静态摘要技术的在线视频播控方法，其中，所述客户端在从所述流媒体服务器下载所述摘要MPD文件之后，将所述摘要MPD文件存储在客户端本地之后进行解析，得到摘要画面的数目、每个摘要画面对应的网址、以及每个摘要画面在原视频文件中的位置，所述位置是时间位置或字节位置。

9.根据权利要求8所述的基于MPEG-DASH协议的带有码率切换控制和静态摘要技术的在线视频播控方法，其中，所述客户端根据所得到的每个摘要画面对应的网址，向用户显示每个摘要画面，所述用户通过点击所显示的某个摘要画面而选择该摘要画面。

10.根据权利要求9所述的基于MPEG-DASH协议的带有码率切换控制和静态摘要技术的在线视频播控方法，其中，所述客户端从所述流媒体服务器下载所述视频片段MPD文件之后，将所述视频片段MPD文件存储在客户端本地之后进行解析，得到所述视频片段的播放信息，所述播放信息包括视频片段的视频格式、编解码器类型、宽度、高度、帧率、网址、视频片段在原视频文件中的位置，所述位置是时间位置或字节位置。

11.根据权利要求10所述的基于MPEG-DASH协议的带有码率切换控制和静态摘要技术的在线视频播控方法，其中，所述客户端根据所述播放信息中的视频片段在原视频文件中的位置，找到距离所选摘要画面最近的视频片段，并向所述流媒体服务器请求从该视频片段开始发送并播放所述目标视频。

12.根据权利要求11所述的基于MPEG-DASH协议的带有码率切换控制和静态摘要技术的在线视频播控方法，其中，所述流媒体服务器在向所述客户端发送视频片段时，通过以下公式确定要发送的视频片段的码率：

$T_e\left(i\right)=\left\{\begin{array}{c}{T}_{\min },i=\mathrm{1,2}\\ \mathrm{\&alpha;}{T}_d(i-1)+(1-\mathrm{\&alpha;})T_d(i-2),i>2\end{array}\right.$

其中，T_e(i)表示即将发送的第i个片段的码率，i为正整数，T_min代表可选的最小发送码率，T_d(i-1)、T_d(i-2)分别为已经发送的第i-1和i-2个片段的实际发送速率，并且，0≤α≤1。