CN103747065A

CN103747065A - 客户端http检索全索引容器格式媒体资源时间片段的方法

Info

Publication number: CN103747065A
Application number: CN201310738843.7A
Authority: CN
Inventors: 许卓明; 吴婷; 倪立显; 何文洁; 庄远航; 王骏华; 仵莉莉
Original assignee: Hohai University HHU
Current assignee: Hohai University HHU
Priority date: 2013-12-27
Filing date: 2013-12-27
Publication date: 2014-04-23
Anticipated expiration: 2033-12-27
Also published as: CN103747065B

Abstract

本发明公开一种客户端HTTP检索全索引容器格式媒体资源时间片段的方法，包括：解析媒体片段URI，获得主资源URI及片段的时间间隔；判断片段是否已在本地HTTP缓存中；判断服务端是否已更新片段的主资源；从本地HTTP缓存中获得片段资源文件，处理结束；向服务端请求并获得主资源的头信息；将片段的时间间隔映射为主资源的字节范围；向服务端请求并获得字节范围；修改头信息，并与字节范围合成为片段资源文件。本发明公开的客户端HTTP检索全索引容器格式媒体资源时间片段的方法能够支持W3C媒体片段URI 1.0标准，由客户端完成时间片段URI向媒体资源字节范围映射并从传统服务端获取字节范围后生成媒体片段文件，从而大大节省通信带宽和缩短通信延时。

Description

客户端HTTP检索全索引容器格式媒体资源时间片段的方法

技术领域

本发明涉及多媒体通信技术领域，尤其涉及一种客户端HTTP检索全索引容器格式媒体资源时间片段的方法。

背景技术

众所周知，图像、音频和视频等多媒体资源是万维网（Web）上的重要信息源。尤其是，近年来兴起的Web 2.0应用（如：共享视频资源的YouTube、优酷等）催生了海量的Web社交媒体资源。然而，各种媒体资源一直是Web的“二等公民”，因为它们必须嵌入到其他Web资源（如HTML网页），依靠“plugin”软件的交互与解码后，视听内容才能被Web用户所访问与消费。为了使多媒体资源成为“一等公民”，Web基础设施技术标准的制订者——万维网联盟（W3C）近年来正在完善Web基础设施，制定相关技术标准。

一般来说，大多数情况下Web用户感兴趣的并不是整个媒体资源，而是媒体资源中的一部分，即媒体片段（media fragment）。例如，一个古典音乐发烧友只想听贝多芬第九交响曲第四乐章中的《欢乐颂》部分，而不是整个交响曲音频；一个破案警察只需要一张街头照片中某嫌疑人的头像部分，而不是包含几十人的完整图像；一个体育频道主持人为了编辑一个“点球”集锦需要从30个足球转播视频中各抽取几分钟的视频剪切，等等。如果这些媒体资源都在Web上由各自的媒体服务器（服务端）维护着，那么Web用户（客户端）用传统技术只能全部下载所有完整媒体资源文件（意味着需耗费巨大的字节流量）后再按需抽取其中的媒体片段，这种方法大大浪费了宝贵的网络带宽，通信延迟也极其严重。因此，需要一套Web机制来支持标识、引用与访问媒体片段。

然而，由于Web媒体资源格式繁多，因此需要制定一种独立于媒体格式的、使用国际标准RFC-3986 URI（参见“Berners-Lee T,Fielding R,Masinter L.RFC 3986:Uniform Resource Identifier(URI):Generic Syntax[S/OL].The Internet Society,January2005.http://www.ietf.org/rfc/rfc3986.txt.”）来定址媒体资源的标准机制。现有的一些多媒体元数据格式定义了依赖于其特定格式的媒体片段标识符，如：SMIL、MPEG-7、TV-Anytime、ImageMaps采用了非URI的标识符，而SVG、Temporal URI/Oggtechnologies、MPEG-21虽采用了基于URI的标识符，但是它们依赖于特定媒体格式，制约了它们在Web上的广泛使用。

W3C认识到以上用户需求的紧迫性及技术现状的不足，于2008年9月正式成立了媒体片段工作组（Media Fragments Working Group），致力于开发独立于媒体格式的、使用基于RFC-3986URI标准的技术规范，来唯一标识与定址（addressing）Web媒体片段；该技术规范应与现有的因特网协议（FILE、HTTP(S)、RTSP）相兼容。该工作组已于2012年9月发布了《媒体片段URI 1.0（基本）标准》（参见“Troncy R,Mannens E,Pfeiffer S,Van Deursen D(Editors),Hausenblas M,

P,Jansen J,Lafon Y,Parker C,Steiner T(Contributors).Media Fragments URI 1.0(basic)[S/OL].W3C Recommendation,25 September 2012.http://www.w3.org/TR/media-frags/.”）。该标准目前支持时间片段（temporal fragment）与空间片段（spatial fragment）的标识。

由于当前Web使用超文本传送协议（简称HTTP协议）国际标准RFC 2616HTTP/1.1（参见“Fielding R,Gettys J,Mogul J,Frystyk H,Masinter L,Leach P,Berners-Lee T.RFC 2616:Hypertext Transfer Protocol--HTTP/1.1[S/OL].The InternetSociety,June 1999.http://www.w3.org/Protocols/rfc2616/rfc2616.html.”），W3C媒体片段工作组认为需要开发一些新HTTP头（如：Content-Range-Mapping header）或新头维（如：Range Request Header dimensions），来指导并期望现有的Web服务端（媒体服务器或代理服务器）下一步能按这种扩充的HTTP协议来进行升级改造，使其成为“懂媒体片段的（media fragments-aware）”服务端；但在服务端未能升级改造之前（目前的情况就是如此），只能开发“懂媒体片段的”客户端，使其能通过传统HTTP协议与传统服务端（即当前任何支持HTTP/1.1协议的Web服务器，如Apache等）进行交互来处理媒体片段URI。

具体而言，W3C的《媒体片段URI 1.0（基本）标准》中规定可使用“URI查询”（URI query）或“URI片段”（URI fragment）两种方式来定址一个由URI标识的媒体资源——称主资源（primary resource）中的某个媒体片段。对于“URI查询”方式而言，“URI查询”定址的解析要求总是由媒体服务器通过转码（transcode）后创建一个与主资源完全无关的新资源返回给请求客户端，这就需要服务端是“懂媒体片段的”，并使用扩充的HTTP协议与客户端进行交互（现阶段还无法完全实现）。对于“URI片段”方式而言，“URI片段”定址的解析则要求从主资源抽取一个媒体类型相同的次生资源（secondary resource），即片段所对应的主资源中某个字节范围（byterange），其HTTP检索过程包括以下步骤：①客户端解析并解释媒体片段URI；②客户端向服务端发出媒体片段检索请求；③通过交互，要么由客户端来直接抽取字节范围，要么由服务端抽取字节范围后分发给客户端。如果“URI片段”定址的解析采用“服务端抽取字节范围”的技术方案，那么服务端必须升级改造成“懂媒体片段的”服务端并使用扩充的HTTP协议与客户端进行交互（现阶段还无法完全实现）；如果采用“客户端直接抽取字节范围”的技术方案，那么“懂媒体片段的”（即：能解析并解释媒体片段URI并支持特定的媒体编解码格式的）客户端可通过传统HTTP协议与传统服务端进行交互来进行处理（这是现阶段较现实的可行技术方案，但现有技术尚未给出完整的解决方法）。不管采用以上何种技术方案，由于“URI片段”定址方式要求媒体片段的抽取无需转码操作，而直接将片段URI映射（mapping）为主资源的字节范围（如：10–20秒的时间片段对应于3000–6000字节范围），因此对媒体格式有特定要求：①对时间片段：需要随机存取点以常规方式出现，以便保持字节等同性（byte-identity），目前大多数媒体（容器）格式能满足此要求；②对空间片段：需要独立编码的空间区域，如兴趣区域（ROIs）与背景是独立编码的，目前大多数媒体（容器）格式无法满足此要求（因此空间片段的定址只能采用“URI查询”方式）。以上情况说明，尽管W3C的《媒体片段URI 1.0（基本）标准》涵盖了时间片段和空间片段的“URI查询”及“URI片段”定址方式，但是，现阶段在这个领域的技术研发主要集中在针对时间片段的“URI片段”定址方式上。

W3C的《媒体片段URI 1.0（基本）标准》中，时间片段在HTTP协议下的“URI片段”定址方式的标准语法格式为：

http://<主机>[:端口]<绝对路径>#<片段定址>

其中：“http://<主机>[:端口]<绝对路径>”部分用于标识主资源；“#<片段定址>”部分用于表示一个时间片段的定址参数，它采用特定的名-值对来表示：名用t表示，值用开始时间和结束时间（如视频编辑中的入点和出点）界定的半开时间间隔（timeinterval）来表示，开始时间（省略时默认为0秒）和结束时间（省略时默认为整个主资源的结束时间点）之间用逗号分隔，可选的时间单位包括：Normal Play Time(npt:)（此为默认单位）、SMPTE(smpte:)、现实世界时钟时间(clock:)，例如：t=npt:10,20表示时间间隔[10,20)；t=,2表示时间间隔[0,20)；t=smpte:0:02:00表示时间间隔[120,end)。

根据以上语法格式，以下时间片段URI：

http://www.example.org/video.mp4#t=npt:68,120

解释为：由“http://www.example.org/video.mp4”这个URI标识的主资源（一个MP4容器格式的媒体资源，其文件名为video.mp4）中，以Normal Play Time为单位的时间间隔为[68,120)的媒体片段（即主资源中第68秒开始一直延续到第120秒结束的部分）。

W3C的《媒体片段URI 1.0（基本）标准》把媒体片段定义为“时间上线性的（time-linear）”，其特点是具有单一的时间轴。容器（container）格式的媒体资源通常包含沿着统一时间轴平行的多个轨的数据，例如视频（video）、音频（audio）、图像（images）及文本（text）等。每个轨的媒体资源有一个包含控制信息的数据头（data header），整个媒体资源通常有一个一般头（general header）。为了能渐进解码，不同数据轨一般以交错方式编码。所有这一切都封装在一个单一的容器文件中。一些支持全索引（full index）的容器格式（如：MP4、AVI、Ogg等）的头信息中包含了时间到字节位移（byte-offset）的映射关系，因此能籍此实现媒体片段的时间间隔到主资源字节范围的映射，也就能较为简单地实现从主资源文件中抽取一个时间片段作为次生资源。

媒体片段在Web上具有广泛用途，W3C媒体片段工作组起草的《媒体片段用例与需求（草案）》（参见“R.Troncy,E.Mannens(Editors),Jansen J,Lafon Y,Pfeiffer S,Van Deursen D(Contributors).Use cases and requirements for Media Fragments[R/OL].W3C Working Draft,17 December 2009.http://www.w3.org/TR/2009/WD-media-frags-reqs-20091217.”）中列举了媒体片段的实际用例，包括：片段的链接、显示或播放、浏览和置书签、重新合成、标注，以及媒体资源的改编等。

关于本领域的相关技术现状，国际上当前主要处在《媒体片段URI 1.0（基本）标准》的制订以及该标准在Web上（尤其是在HTTP协议下）具体实施方式方法的讨论阶段。W3C媒体片段工作组成员公开发表在国际学术期刊《多媒体工具与应用》的相关论文中（参见“Van Lancker W,Van Deursen D,Mannens E,Van de Walle R.Implementation strategies for efficient media fragment retrieval[J].Multimedia Tools andApplications,March 2012,57(2):243-267.”）讨论并比较了媒体片段HTTP检索的几种可能的实现策略，得出的结论是：①已有研究主要集中在探讨如何将服务端（媒体服务器或代理服务器）按扩充的HTTP协议升级改造为“懂媒体片段的”服务端（如：作为URI 1.0概念证明的NinSuna服务器），或如何开发媒体片段的（第三方）翻译服务器（如：作为URI 1.0概念证明的MFTS翻译服务设想）；②目前尚没有能通过传统HTTP协议与传统服务端进行交互来处理媒体片段URI的“懂媒体片段的”客户端实现。

最近，一些部分支持HTML5候选标准（参见“Berjon R,Faulkner S,Leithead T,Doyle Navara E,O′Connor E,Pfeiffer S,Hickson I(Editors).HTML5:A vocabulary andassociated APIs for HTML and XHTML[R/OL].W3C Candidate Recommendation,6August 2013:http://www.w3.org/TR/2013/CR-html5-20130806/.”）的最新版浏览器（如：MozillaFirefox和Google Chrome等）能部分支持媒体片段URI1.0标识的时间片段的在线播放，其不足之处是仅部分支持时间片段URI1.0语法，且只能在浏览器中对时间片段进行在线播放，而不能让客户端抽取并获得时间片段资源文件，因此无法进一步支持实现W3C《媒体片段用例与需求（草案）》中所要求的多种片段实际用例，包括：片段的链接、浏览和置书签、重新合成、标注，以及媒体资源的改编等。

中国专利号CN 101577627 B，公开日2011年9月9日，授权公告日2011年12月14日，发明创造的名称为“多媒体文件的下载播放***及方法”，该已授权发明专利公开了一种多媒体文件的下载播放***及方法，其所述方法包括：下载多媒体文件的头部信息；解析头部信息，并根据头部信息获取多媒体数据的下载位置信息；根据下载位置信息下载多媒体数据以及播放下载的多媒体数据。该发明专利技术方案的主要缺陷包括：完全不支持W3C的《媒体片段URI 1.0（基本）标准》；只能在线播放多媒体文件，无法使客户端获取时间片段资源文件；客户端与服务端之间以及客户端的播放单元与下载单元之间需要不断进行复杂的交互；只宏观上描述了下载、解析多媒体文件头部信息并据此获取多媒体数据下载位置的步骤（不足以说明其技术方案针对各种多媒体格式的可实施性与实用性），特别地，未具体描述针对全索引容器格式媒体资源时间片段的技术方案，也未具体给出相应的HTTP请求/响应协议步骤。

因此，本发明要解决的技术问题是针对符合W3C媒体片段URI 1.0标准的全索引容器格式媒体资源的时间片段，有必要提出一种无需改造现有的媒体服务器和无需扩充HTTP协议，而由客户端通过传统HTTP协议来检索并获取时间片段文件的方法，以避免对当前Web基础设施的改造，并且比下载完整媒体资源的传统技术方案大大节省通信带宽和缩短通信延时。

发明内容

本发明的目的旨在提供一种客户端的媒体资源时间片段的检索方法，无需改造现有的媒体服务器和无需扩充HTTP协议，而由客户端通过传统HTTP协议来检索并获取时间片段文件的方法，以避免对当前Web基础设施的改造，并且比下载完整媒体资源的传统技术方案大大节省通信带宽和缩短通信延时。

本发明提出一种客户端HTTP检索全索引容器格式媒体资源时间片段的方法，包括：S1，解析媒体片段URI，获得主资源URI及片段的时间间隔；S2，判断片段是否已在本地HTTP缓存中：若是则执行步骤S3，否则执行步骤S5；S3，判断服务端是否已更新片段的主资源：若是则执行步骤S5，否则执行步骤S4；S4，从本地HTTP缓存中获得片段资源文件，处理结束；S5，向服务端请求并获得主资源的头信息；S6，将片段的时间间隔映射为主资源的字节范围；S7，向服务端请求并获得字节范围；S8，修改头信息，并与字节范围合成为片段资源文件。

本发明提出的一种媒体资源时间片段的客户端检索方法，能够支持W3C媒体片段URI 1.0标准，由客户端完成时间片段URI向媒体资源字节范围映射并从传统服务端获取字节范围后生成媒体片段文件，从而无需改造现有的媒体服务器和无需扩充HTTP协议，而由客户端通过传统HTTP协议来检索并获取时间片段文件的方法，以避免对当前Web基础设施的改造，并且比下载完整媒体资源的传统技术方案大大节省通信带宽和缩短通信延时。

本发明附加的方面和优点将在下面的描述中部分给出，这些将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

图1示出了根据本发明技术方案的客户端HTTP检索全索引容器格式媒体资源时间片段的方法的流程示意图；

图2示出了根据本发明技术方案的客户端HTTP检索全索引容器格式媒体资源时间片段的处理过程中与服务端进行HTTP通信的方法的流程示意图；

图3示出了根据本发明技术方案的客户端解析媒体片段URI并获得主资源URI及片段的时间间隔的流程示意图；

图4示出了根据本发明技术方案的客户端将媒体片段的时间间隔映射为主资源的字节范围的流程示意图。

具体实施方式

下面详细描述本发明的实施方式，所述实施方式的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的概念、对象、要素等或具有相同或类似功能的概念、对象、要素等。下面通过参考附图描述的实施方式是示例性的，仅用于解释本发明，而不能解释为对本发明的限制。

本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语（包括技术术语和科学术语）具有与本发明所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非像这里一样定义，不会用理想化或过于正式的含义来解释。

图1示出了根据本发明技术方案的客户端HTTP检索全索引容器格式媒体资源时间片段的方法的流程示意图。如图1所示，本发明提出一种客户端HTTP检索全索引容器格式媒体资源时间片段的方法，包括：S1，解析媒体片段URI，获得主资源URI及片段的时间间隔；S2，判断片段是否已在本地HTTP缓存中：若是则执行步骤S3，否则执行步骤S5；S3，判断服务端是否已更新片段的主资源：若是则执行步骤S5，否则执行步骤S4；S4，从本地HTTP缓存中获得片段资源文件，处理结束；S5，向服务端请求并获得主资源的头信息；S6，将片段的时间间隔映射为主资源的字节范围；S7，向服务端请求并获得字节范围；S8，修改头信息，并与字节范围合成为片段资源文件。

进一步地，解析媒体片段URI，获得主资源URI及片段的时间间隔，包括：以片段URI中的“#”为分割点获取主资源URI部分和片段定址部分；判断主资源URI部分是否符合RFC-3986 URI语法，若否，则报错并终止；判断片段定址部分是否符合媒体片段URI 1.0语法，若否，则报错并终止；根据时间单位计算出以秒为计的开始时间与结束时间；判断开始时间是否小于结束时间，若否，则报错并终止；根据以秒为计的开始时间与结束时间计算出时间间隔。

进一步地，判断服务端是否已更新片段的主资源，包括：客户端向服务端发送一个HTTP If-Modified-Since条件GET请求；客户端收到服务端的状态码响应后，根据状态码进行判断：若状态码为HTTP 304 Not Modified则表示服务端未更新片段的主资源，若状态码为HTTP 412 Precondition Failed则表示服务端已更新片段的主资源。

进一步地，向服务端请求并获得主资源的头信息，包括：根据主资源文件名的后缀名确定具体的容器格式；根据该容器格式确定头信息的位置与字节大小，由此确定主资源的头信息在该媒体资源中的字节范围；向服务端发送HTTP字节范围GET请求；接收服务端返回的HTTP 206 Partial Content状态码响应及该响应中所含的头信息二进制数据。

进一步地，将片段的时间间隔映射为主资源的字节范围，包括：按容器格式的头信息数据结构从主资源头信息的二进制数据中提取信息；将片段时间间隔转换为媒体时间坐标***中的时间间隔；在头信息数据结构中查找到时间间隔所对应的样本序号；在头信息数据结构中查找到与样本序号最接近的关键帧序号；在头信息数据结构中查找到最接近关键帧在主资源文件中的字节位移，据此计算出字节范围。

进一步地，向服务端请求并获得字节范围，包括：向服务端发送HTTP字节范围GET请求；接收服务端返回的HTTP 206 Partial Content状态码响应及该响应中所含的字节范围二进制数据。

进一步地，修改头信息，并与字节范围合成为片段资源文件，包括：修改主资源文件的头信息二进制数据；将修改后的头信息二进制数据与字节范围二进制数据合成为片段资源文件。

本发明提出的一种客户端的媒体资源时间片段的检索方法，能够支持W3C媒体片段URI 1.0标准，由客户端完成时间片段URI向媒体资源字节范围映射并从传统服务端获取字节范围后生成媒体片段文件，从而无需改造现有的媒体服务器和无需扩充HTTP协议，而由客户端通过传统HTTP协议来检索并获取时间片段文件的方法，以避免对当前Web基础设施的改造，并且比下载完整媒体资源的传统技术方案大大节省通信带宽和缩短通信延时。

下文将对上述各步骤具体展开描述。为便于理解，如下表1中列出了相关步骤中客户端与服务端进行HTTP通信时使用的HTTP请求/响应中包含的主要术语及其含义：

表1：本发明技术方案使用的HTTP请求/响应中包含的主要术语及其含义

为了解决上述技术问题，本发明是通过以下技术方案实现的：

图1示出了根据本发明技术方案的客户端HTTP检索全索引容器格式媒体资源时间片段的方法的流程示意图。图2示出了根据本发明技术方案的客户端HTTP检索全索引容器格式媒体资源时间片段的处理过程中与服务端进行HTTP通信的方法的流程示意图。

如图1和图2所示，客户端HTTP检索全索引容器格式媒体资源时间片段的方法，包括如下步骤：

步骤S1，解析媒体片段URI，获得主资源URI及片段的时间间隔。图3示出了根据本发明技术方案的客户端解析媒体片段URI并获得主资源URI及片段的时间间隔的流程示意图。如图3所示，具体包括：

步骤S1-1，以片段URI中的“#”为分割点获取主资源URI部分和片段定址部分。

步骤S1-2，判断主资源URI部分是否符合RFC-3986 URI语法，若否，则报错并终止。

步骤S1-3，判断片段定址部分是否符合媒体片段URI1.0语法，若否，则报错并终止。

步骤S1-4，根据时间单位计算出以秒为计的开始时间与结束时间。

步骤S1-5，判断开始时间是否小于结束时间，若否，则报错并终止。

步骤S1-6，根据以秒为计的开始时间与结束时间计算出时间间隔。

步骤S2，判断片段是否已在本地HTTP缓存中？若是，则执行步骤S3；否则执行步骤S5。

步骤S3，判断服务端是否已更新片段的主资源？若是，则执行步骤S5；否则执行步骤S4。

判断服务端是否已更新片段的主资源的方法如下：

首先，客户端向服务端发送一个HTTP If-Modified-Since条件GET请求，其请求如下：

GET<绝对路径>HTTP/1.1

Host:<主机>

Accept:video/*

If-Modified-Since:<HTTP-datetime>

If-None-Match:*|<1#entity-tag>（注：实体标签）

然后，服务端收到客户端发送的HTTP请求后检查媒体资源是否已更新，如果未更新则返回一个HTTP 304 Not Modified状态码响应；如果已更新则返回一个HTTP412 Precondition Failed状态码响应。

最后，客户端收到服务端的状态码响应后，根据状态码进行判断：若状态码为304则表示服务端未更新片段的主资源，若状态码为412则表示服务端已更新片段的主资源。

步骤S4，从本地HTTP缓存中获得片段资源文件；处理结束。

步骤S5，向服务端请求并获得主资源的头信息，具体包括：

首先，根据主资源文件名的后缀名确定具体的容器格式，根据此容器格式确定头信息的位置与字节大小，由此确定主资源的头信息在该媒体资源中的字节范围。

然后，客户端向服务端发送HTTP字节范围GET请求，其请求如下：

GET<绝对路径>HTTP/1.1

Host:<主机>

Accept:video/*

Range:bytes=<头信息首字节位置>-<头信息尾字节位置>

最后，服务端得到以上请求后，从主资源文件中抽取头信息字节范围，并以HTTP206Partial Content状态码响应及该响应中所含的头信息二进制数据返回给客户端，其响应（内含消息体）如下：

HTTP/1.1 206 Partial Content

Accept-Ranges:bytes

Content-Length:<片段总字节数>

Content-Type:video/<网络媒体类型>

Content-Range:bytes<首字节位置>-<尾字节位置>/<主资源总字节数>

{binary data}（注：头信息的二进制数据）

步骤S6，将片段的时间间隔映射为主资源的字节范围。图4示出了根据本发明技术方案的客户端将媒体片段的时间间隔映射为主资源的字节范围的流程示意图。如图4所示，具体包括：

步骤S6-1，按容器格式的头信息数据结构从主资源头信息的二进制数据中提取信息。

步骤S6-2，将片段时间间隔转换为媒体时间坐标***中的时间间隔。

步骤S6-3，在头信息数据结构中查找到时间间隔所对应的样本序号。

步骤S6-4，在头信息数据结构中查找到与样本序号最接近的关键帧序号。

步骤S6-5，在头信息数据结构中查找到最接近关键帧在主资源文件中的字节位移，据此计算出字节范围。

步骤S7，向服务端请求并获得字节范围，具体包括：

首先，客户端向服务端发送HTTP字节范围GET请求，请求如下：

GET<绝对路径>HTTP/1.1

Host:<主机>

Accept:video/*

Range:bytes=<首字节位置1>-<尾字节位置2>,...,<首字节位置n>-<尾字节位置n>

最后，服务端收到以上请求后，从主资源文件中抽取相应字节范围，并以HTTP206Partial Content状态码响应及该响应中所含的字节范围二进制数据返回给客户端，其响应（内含消息体）如下：

HTTP/1.1 206 Partial Content

Accept-Ranges:bytes

Content-Length:<片段总字节数>

Content-Type:multipart/byteranges;boundary=THIS_STRING_SEPARATES

--THIS_STRING_SEPARATES

Content-Type:video/<网络媒体类型>

Content-Range:bytes<首字节位置1>-<尾字节位置1>/<主资源总字节数>

{binary data}（注：字节范围的二进制数据1）

...

--THIS_STRING_SEPARATES

Content-Type:video/<网络媒体类型>

Content-Range:bytes<首字节位置n>-<尾字节位置n>/<主资源总字节数>

{binary data}（注：字节范围的二进制数据n）

步骤S8，修改头信息，并与字节范围合成为片段资源文件，具体包括：

步骤S8-1，修改主资源文件的头信息二进制数据。步骤S8-2，将修改后的头信息二进制数据与字节范围二进制数据合成为片段资源文件。

本发明的技术方案是由客户端与服务端通过传统的HTTP协议进行交互而实现的，因此无需扩充HTTP协议，也无需对现有的媒体服务器端进行升级改造；本技术方案由客户端完成时间片段URI向媒体资源字节范围的映射，只向服务端请求了媒体资源的头信息和片段字节范围，因此比下载完整媒体资源的技术方案大大节省了通信带宽、缩短了通信延时；由于本技术方案可获得时间片段文件，因此支持各式各样的客户端应用对所获时间片段的复用，包括媒体片段的播放、标注或置书签、重新合成、以及媒体资源改编等。

下文将结合以上内容以MP4（参见“International Standard:ISO/IEC14496-14:2003Information technology--Coding of audio-visual objects--Part 14:MP4 file format[S/OL].First edition,ISO/IEC,2003.http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=38538.”）这种万维网上流行的、典型的全索引容器格式媒体资源为例，来进一步说明本发明技术方案的具体实施方式。

具体实施方式以MP4格式媒体资源的时间片段URI：http://www.example.org/video.mp4#t=npt:100,220（设主资源文件video.mp4的总字节数为20971520）为例。图1示出了根据本发明技术方案的客户端HTTP检索全索引容器格式（本实施例中为MP4格式）媒体资源时间片段的方法的流程示意图；图2示出了根据本发明技术方案的客户端HTTP检索全索引容器格式（本实施例中为MP4格式）媒体资源时间片段的处理过程中与服务端进行HTTP通信的方法的流程示意图。如图1与图2所示，客户端HTTP检索以上MP4格式媒体资源时间片段的方法，包括如下步骤：

步骤S1，解析媒体片段URI，获得主资源URI及片段的时间间隔。图3示出了根据本发明技术方案的解析媒体片段URI并获得主资源URI及片段的时间间隔的流程示意图。如图3所示，具体包括：

步骤S1-1，以片段URI中的“#”为分割点获取主资源URI部分和片段定址部分，具体包括：

获取主资源URI部分为：http://www.example.org/video.mp4

获取片段定址部分为：t=npt:100,220。

判断结果为：主资源URI部分符合RFC-3986 URI语法。

步骤S1-3，判断片段定址部分是否符合媒体片段URI 1.0语法，若否，则报错并终止。

判断结果为：片段定址部分符合媒体片段URI 1.0语法。

步骤S1-4，根据时间单位计算出以秒为计的开始时间与结束时间，具体包括：

计算出开始时间为：100（秒）

计算出结束时间为：220（秒）。

判断结果为：开始时间小于结束时间。

步骤S1-6，根据以秒为计的开始时间与结束时间计算出时间间隔，具体包括：

计算出时间间隔为：[100,220)。

如果片段已在本地HTTP缓存中，那么下一步执行步骤S3；否则，下一步执行步骤S5。

如图2所示，判断服务端是否已更新片段的主资源的方法如下：

GET<绝对路径>HTTP/1.1

Host:www.example.org

Accept:video/*

If-Modified-Since:Sat,07 Dec 2013 14:28:35GMT

If-None-Match:“b7a60-21f7412-46f3947216850”

步骤S4，从本地缓冲区中获得片段资源文件；处理结束。

步骤S5，向服务端请求并获得主资源的头信息，具体包括：

首先，根据主资源文件名的后缀名确定是MP4容器格式，根据MP4格式确定头信息的位置与字节大小，由此确定主资源的头信息在该媒体资源中的字节范围。MP4格式的头信息包含ftyp和moov两个原子，位置在MP4资源文件的最前面，这两个原子的字节大小用如下步骤来确定：客户端向服务端发送HTTP字节范围请求，只请求主资源文件的前4个字节（从字节0到字节3），其中表示了MP4资源文件中的ftyp原子的大小（设为LengthOfFtyp），因为ftyp原子后面是用来封装MP4所有描述信息的moov原子，所以第(LengthOfFtyp+1)个字节便是moov原子的第一个字节；客户端向服务端发送HTTP字节范围请求，只请求主资源文件中从字节LengthOfFtyp到字节(LengthOfFtyp+3)的范围，该字节范围表示了moov原子的大小（设为LengthOfMoov），则从第LengthOfFtyp到第(LengthOfFtyp+LengthOfMoov)个字节便存放了整个moov原子的内容。于是，从字节0到字节(LengthOfFtyp+LengthOfMoov-1)的范围便是主资源MP4文件头信息的字节范围。

GET/video.mp4 HTTP/1.1

Host:www.example.org

Accept:video/*

Range:bytes=0-(LengthOfFtyp+LengthOfMoov-1)

HTTP/1.1 206 Partial Content

Accept-Ranges:bytes

Content-Length:(LengthOfFtyp+LengthOfMoov)

Content-Type:video/mp4

Content-Range:bytes0-(LengthOfFtyp+LengthOfMoov-1)/20971520

{binary data}（注：头信息的二进制数据）

步骤S6，将片段的时间间隔映射为主资源的字节范围，其处理流程见图4所示，具体包括：

步骤S6-1，按容器格式的头信息数据结构从主资源头信息的二进制数据中提取信息，具体包括：

提取出MP4容器格式头信息数据结构中的相关信息。

步骤S6-2，将片段时间间隔转换为媒体时间坐标***中的时间间隔，具体包括：

由于MP4格式头信息中音频轨与视频轨的结构相同，这里仅以视频轨为例来说明：在头信息视频轨中查找到媒体时间标度（设为TimeScale），则可转换得到媒体时间坐标***中的开始时间StartTime=100*TimeScale，结束时间EndTime=220*TimeScale。

步骤S6-3，在头信息数据结构中查找到时间间隔所对应的样本序号，具体包括：

根据头信息数据结构中的时间到样本的映射表stts（指time-to-sample）计算出给定时间间隔所对应的样本序号（设为SampleNumOfStartTime和SampleNumOfEndTime）。

步骤S6-4，在头信息数据结构中查找到与样本序号最接近的关键帧序号，具体包括：

关键帧序号在映射表stss（指sync sample atom）中表示。若stss不存在，说明每一个样本都是一个关键帧，则SampleNumOfStartTime和SampleNumOfEndTime就是要查找的关键帧序号；若stss存在，则查找到与SampleNumOfStartTime和SampleNumOfEndTime样本最接近的关键帧序号。

步骤S6-5，在头信息数据结构中查找到最接近关键帧在主资源文件中的字节位移，据此计算出字节范围，具体包括：

首先，根据头信息中样本到块的映射表stsc（指sample-to-chunk）确定最接近的关键帧所在的块（chunk）序号。

接着，根据头信息中块的位移映射表stco（指chunk offset atom）确定块在主资源文件中的字节位移。

然后，确定最接近关键帧在主资源文件中的字节位移：根据样本的字节大小映射表stsz（指sample size atom）计算出在块中最接近关键帧之前的样本字节大小之和；根据块中最接近关键帧之前的样本字节大小之和与所得的块在媒体文件中的字节位移，计算出最接近关键帧在媒体文件中的字节位移。

最后，根据字节位移计算出字节范围，设为从字节FirstByte1到字节LastByte1，从字节FirstByte2到字节LastByte2，以及从字节FirstByte3到字节LastByte3。

步骤S7，向服务端请求并获得字节范围，具体包括：

首先，客户端向服务端发送HTTP字节范围GET请求，请求如下：

GET/video.mp4 HTTP/1.1

Host:www.example.org

Accept:video/*

Range:bytes=FirstByte1-LastByte1,FirstByte2-LastByte2,FirstByte3-LastByte3

最后，服务端收到以上请求后，从主资源文件中抽取相应字节范围，并以HTTP206 Partial Content状态码响应及该响应中所含的字节范围二进制数据返回给客户端，其响应（内含消息体）如下：

HTTP/1.1 206 Partial Content

Accept-Ranges:bytes

Content-Length:((LastByte1-FirstByte1+1)+(LastByte2-FirstByte2+1)+

(LastByte3-FirstByte3+1))

Content-Type:multipart/byteranges;boundary=THIS_STRING_SEPARATES

--THIS_STRING_SEPARATES

Content-type:video/mp4

Content-range:bytes FirstByte1-LastByte1/20971520

{binary data}（注：字节范围的二进制数据1）

--THIS_STRING_SEPARATES

Content-type:video/mp4

Content-range:bytes FirstByte2-LastByte2/20971520

{binary data}（注：字节范围的二进制数据2）

--THIS_STRING_SEPARATES

Content-type:video/mp4

Content-Range:bytes FirstByte3-LastByte3/20971520

{binary data}（注：字节范围的二进制数据3）

步骤S8-1，修改主资源文件的头信息二进制数据，具体包括：

修改stts、stsc、stco、stsz、stss映射表，删除开始号样本之前和结束号样本之后的映射表信息，修改映射表长度以及整个映射表原子的字节大小。

修改mdhd（指media header）中的持续时间duration。

逐层修改外层原子的字节大小，同时更新mvhd（指movie header）原子中的持续时间以及整个moov原子的大小。

修改块的字节位移表stco（指chunk offset atom）中的偏移量。

步骤S8-2，将修改后的头信息二进制数据与字节范围二进制数据合成为片段资源文件，具体包括：

在字节范围的数据之前增加8个字节来指定该数据的大小为8+((LastByte1-FirstByte1+1)+(LastByte2-FirstByte2+1)+(LastByte3-FirstByte3+1))以及mdat（指media data）原子类型。

本技术领域技术人员可以理解，本发明中所述的“客户端”与“服务端”是指HTTP/1.1协议（或未来的升级版）的国际标准中所述的“客户端”与“服务端”。根据HTTP/1.1协议的国际标准，“客户端”是指为发送请求（requests）的目的而与服务端建立连接（connections）计算机程序，无论该计算机程序以何种方式运行于何种类型的客户端设备；“服务端”是指为响应（respond）客户端请求（requests）的目的而接受连接（connections）或由第三方代理其接受连接的计算机程序，无论该计算机程序以何种方式运行于何种类型的服务端设备。

本技术领域技术人员可以理解，本发明可以涉及用于执行本申请中所述操作中的一项或多项操作的设备。所述设备可以为所需的目的而专门设计和制造，或者也可以包括通用计算机中的已知设备，所述通用计算机有存储在其内的程序选择性地激活或重构。这样的计算机程序可以被存储在设备（例如，计算机）可读介质中或者存储在适于存储电子指令并分别耦联到总线的任何类型的介质中，所述计算机可读介质包括但不限于任何类型的盘（包括软盘、硬盘、光盘、CD-ROM、和磁光盘）、随即存储器（RAM）、只读存储器（ROM）、电可编程ROM、电可擦ROM（EPROM）、电可擦除可编程ROM（EEPROM）、闪存、磁性卡片或光线卡片。可读介质包括用于以由设备（例如，计算机）可读的形式存储或传输信息的任何机构。例如，可读介质包括随即存储器（RAM）、只读存储器（ROM）、磁盘存储介质、光学存储介质、闪存装置、以电的、光的、声的或其他的形式传播的信号（例如载波、红外信号、数字信号）等。

本技术领域技术人员可以理解，可以用计算机程序指令来实现这些结构图和/或框图和/或流图中的每个框以及这些结构图和/或框图和/或流图中的框的组合。可以将这些计算机程序指令提供给通用计算机、专业计算机或其他可编程数据处理方法的处理器来生成机器，从而通过计算机或其他可编程数据处理方法的处理器来执行的指令创建了用于实现结构图和/或框图和/或流图的框或多个框中指定的方法。

本技术领域技术人员可以理解，本发明中已经讨论过的各种操作、方法、流程中的步骤、措施、方案可以被交替、更改、组合或删除。进一步地，具有本发明中已经讨论过的各种操作、方法、流程中的其他步骤、措施、方案也可以被交替、更改、重排、分解、组合或删除。进一步地，现有技术中的具有与本发明中公开的各种操作、方法、流程中的步骤、措施、方案也可以被交替、更改、重排、分解、组合或删除。

以上所述仅是本发明的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims

1.一种客户端HTTP检索全索引容器格式媒体资源时间片段的方法，其特征在于，包括：

S1，解析媒体片段URI，获得主资源URI及片段的时间间隔；

S2，判断片段是否已在本地HTTP缓存中：若是则执行步骤S3，否则执行步骤S5；

S3，判断服务端是否已更新片段的主资源：若是则执行步骤S5，否则执行步骤S4；

S4，从本地HTTP缓存中获得片段资源文件，处理结束；

S5，向服务端请求并获得主资源的头信息；

S6，将片段的时间间隔映射为主资源的字节范围；

S7，向服务端请求并获得字节范围；

S8，修改头信息，并与字节范围合成为片段资源文件。

2.如权利要求1所述的客户端HTTP检索全索引容器格式媒体资源时间片段的方法，其特征在于，解析媒体片段URI，获得主资源URI及片段的时间间隔，包括：

以片段URI中的“#”为分割点获取主资源URI部分和片段定址部分；

判断主资源URI部分是否符合RFC-3986URI语法，若否，则报错并终止；

判断片段定址部分是否符合媒体片段URI 1.0语法，若否，则报错并终止；

根据时间单位计算出以秒为计的开始时间与结束时间；

判断开始时间是否小于结束时间，若否，则报错并终止；

根据以秒为计的开始时间与结束时间计算出时间间隔。

3.如权利要求1所述的客户端HTTP检索全索引容器格式媒体资源时间片段的方法，其特征在于，判断服务端是否已更新片段的主资源，包括：

向服务端发送一个HTTP If-Modified-Since条件GET请求；

收到服务端的状态码响应后，根据状态码进行判断：若状态码为HTTP 304 NotModified则表示服务端未更新片段的主资源，若状态码为HTTP 412 PreconditionFailed则表示服务端已更新片段的主资源。

4.如权利要求1所述的客户端HTTP检索全索引容器格式媒体资源时间片段的方法，其特征在于，向服务端请求并获得主资源的头信息，包括：

根据主资源文件名的后缀名确定具体的容器格式；

根据该容器格式确定头信息的位置与字节大小，由此确定主资源的头信息在该媒体资源中的字节范围；

向服务端发送HTTP字节范围GET请求；

接收服务端返回的HTTP 206 Partial Content状态码响应及该响应中所含的头信息二进制数据。

5.如权利要求1所述的客户端HTTP检索全索引容器格式媒体资源时间片段的方法，其特征在于，将片段的时间间隔映射为主资源的字节范围，包括：

按容器格式的头信息数据结构从主资源头信息的二进制数据中提取信息；

将片段时间间隔转换为媒体时间坐标***中的时间间隔；

在头信息数据结构中查找到时间间隔所对应的样本序号；

在头信息数据结构中查找到与样本序号最接近的关键帧序号；

在头信息数据结构中查找到最接近关键帧在主资源文件中的字节位移，据此计算出字节范围。

6.如权利要求1所述的客户端HTTP检索全索引容器格式媒体资源时间片段的方法，其特征在于，向服务端请求并获得字节范围，包括：

向服务端发送HTTP字节范围GET请求；

接收服务端返回的HTTP 206 Partial Content状态码响应及该响应中所含的字节范围二进制数据。

7.如权利要求1所述的客户端HTTP检索全索引容器格式媒体资源时间片段的方法，其特征在于，修改头信息，并与字节范围合成为片段资源文件，包括：

修改主资源文件的头信息二进制数据；

将修改后的头信息二进制数据与字节范围二进制数据合成为片段资源文件。