客戶端http檢索全索引容器格式媒體資源時間片段的方法
【專利摘要】本發(fā)明公開一種客戶端HTTP檢索全索引容器格式媒體資源時間片段的方法，包括：解析媒體片段URI，獲得主資源URI及片段的時間間隔；判斷片段是否已在本地HTTP緩存中；判斷服務端是否已更新片段的主資源；從本地HTTP緩存中獲得片段資源文件，處理結(jié)束；向服務端請求并獲得主資源的頭信息；將片段的時間間隔映射為主資源的字節(jié)范圍；向服務端請求并獲得字節(jié)范圍；修改頭信息，并與字節(jié)范圍合成為片段資源文件。本發(fā)明公開的客戶端HTTP檢索全索引容器格式媒體資源時間片段的方法能夠支持W3C媒體片段URI?1.0標準，由客戶端完成時間片段URI向媒體資源字節(jié)范圍映射并從傳統(tǒng)服務端獲取字節(jié)范圍后生成媒體片段文件，從而大大節(jié)省通信帶寬和縮短通信延時。
【專利說明】客戶端HTTP檢索全索引容器格式媒體資源時間片段的方法
【技術領域】
[0001]本發(fā)明涉及多媒體通信【技術領域】，尤其涉及一種客戶端HTTP檢索全索引容器格式媒體資源時間片段的方法。
【背景技術】
[0002]眾所周知，圖像、音頻和視頻等多媒體資源是萬維網(wǎng)(Web)上的重要信息源。尤其是，近年來興起的Web 2.0應用(如:共享視頻資源的YouTube、優(yōu)酷等)催生了海量的Web社交媒體資源。然而，各種媒體資源一直是Web的“二等公民”，因為它們必須嵌入到其他Web資源(如HTML網(wǎng)頁)，依靠“plugin”軟件的交互與解碼后，視聽內(nèi)容才能被Web用戶所訪問與消費。為了使多媒體資源成為“一等公民”，Web基礎設施技術標準的制訂者一萬維網(wǎng)聯(lián)盟(W3C)近年來正在完善Web基礎設施，制定相關技術標準。
[0003]一般來說，大多數(shù)情況下Web用戶感興趣的并不是整個媒體資源，而是媒體資源中的一部分，即媒體片段(media fragment)。例如,一個古典音樂發(fā)燒友只想聽貝多芬第九交響曲第四樂章中的《歡樂頌》部分，而不是整個交響曲音頻；一個破案警察只需要一張街頭照片中某嫌疑人的頭像部分，而不是包含幾十人的完整圖像；一個體育頻道主持人為了編輯一個“點球”集錦需要從30個足球轉(zhuǎn)播視頻中各抽取幾分鐘的視頻剪切，等等。如果這些媒體資源都在Web上由各自的媒體服務器(服務端)維護著，那么Web用戶(客戶端)用傳統(tǒng)技術只能全部下載所有完整媒體資源文件(意味著需耗費巨大的字節(jié)流量)后再按需抽取其中的媒體片段，這種方法大大浪費了寶貴的網(wǎng)絡帶寬，通信延遲也極其嚴重。因此，需要一套Web機制來支持標識、引用與訪問媒體片段。
[0004]然而，由于Web媒體資源格式繁多，因此需要制定一種獨立于媒體格式的、使用國際標準 RFC-3986 URI (參見 “Berners-Lee T, Fielding R, Masinter L.RFC3986: Uniform Resource Identifier (URI): Generic Syntax[S/0L].The InternetSociety,.Tanuary2005.http://www.1etf.0rR/rfc/rfc3986.txt.，，)來定址媒體資源的標準機制?，F(xiàn)有的一些多媒體元數(shù)據(jù)格式定義了依賴于其特定格式的媒體片段標識符，如:SMIL、MPEG-7、TV-Anytime, ImageMaps 采用了非 URI 的標識符，而 SVG、Temporal URI/0ggtechnologies, MPEG-21雖采用了基于URI的標識符，但是它們依賴于特定媒體格式，制約了它們在Web上的廣泛使用。
[0005]W3C認識到以上用戶需求的緊迫性及技術現(xiàn)狀的不足，于2008年9月正式成立了媒體片段工作組(Media Fragments Working Group),致力于開發(fā)獨立于媒體格式的、使用基于RFC-3986URI標準的技術規(guī)范，來唯一標識與定址(addressing) Web媒體片段；該技術規(guī)范應與現(xiàn)有的因特網(wǎng)協(xié)議(FILE、HTTP(S)、RTSP)相兼容。該工作組已于2012年9月發(fā)布了《媒體片段URI 1.0 (基本)標準》(參見“Troncy R, Mannens E, Pfeiffer S，VanDeursen D(Editors), Hausenblas M, Jagcnstcdt P, Jansen J, Lafon Y, Parker C, SteinerT (Contributors).Media Fragments URI 1.0(basic)[S/0L].W3C Recommendation, 25September 2012.http: / / www.w3.0rg/TR/media-frags/.，，)。該標準目前支持時間片段(temporal fragment)與空間片段(spatial fragment)的標識。
[0006]由于當前Web使用超文本傳送協(xié)議(簡稱HTTP協(xié)議)國際標準RFC 2616HTTP/1.1(參見 “Fielding R, Gettys J, Mogul J, Frystyk H, Masinter L, Leach P, Berners-LeeT.RFC 2616: Hypertext Transfer Protocol—HTTP/1.I[S/OL].The InternetSociety, June 1999.http: //www.w3.0rg/Protocols/rfc2616/rfc2616.html.，，), W3C 媒體片段工作組認為需要開發(fā)一些新HTTP頭(如:Content-Range-Mapping header)或新頭維(如:Range Request Header dimensions),來指導并期望現(xiàn)有的Web服務端(媒體服務器或代理服務器)下一步能按這種擴充的HTTP協(xié)議來進行升級改造，使其成為“懂媒體片段的(media fragments-aware)”服務端；但在服務端未能升級改造之前(目前的情況就是如此)，只能開發(fā)“懂媒體片段的”客戶端，使其能通過傳統(tǒng)HTTP協(xié)議與傳統(tǒng)服務端(即當前任何支持HTTP/1.1協(xié)議的Web服務器，如Apache等)進行交互來處理媒體片段URI。
[0007]具體而言，W3C的《媒體片段URI 1.0 (基本)標準》中規(guī)定可使用“URI查詢”(URI
query)或“URI片段”(URI fragment)兩種方式來定址一個由URI標識的媒體資源-稱
主資源(primary resource)中的某個媒體片段。對于“URI查詢”方式而言,“URI查詢”定址的解析要求總是由媒體服務器通過轉(zhuǎn)碼(transcode)后創(chuàng)建一個與主資源完全無關的新資源返回給請求客戶端，這就需要服務端是“懂媒體片段的”，并使用擴充的HTTP協(xié)議與客戶端進行交互(現(xiàn)階段還無法完全實現(xiàn))。對于“URI片段”方式而言，“URI片段”定址的解析則要求從主資源抽取一個媒體類型相同的次生資源(secondary resource),即片段所對應的主資源中某個字節(jié)范圍(byte range),其HTTP檢索過程包括以下步驟:①客戶端解析并解釋媒體片段URI ;②客戶端向服務端發(fā)出媒體片段檢索請求；③通過交互,要么由客戶端來直接抽取字節(jié)范圍，要么由服務端抽取字節(jié)范圍后分發(fā)給客戶端。如果“URI片段”定址的解析采用“服務端抽取字節(jié)范圍”的技術方案，那么服務端必須升級改造成“懂媒體片段的”服務端并使用擴充的HTTP協(xié)議與客戶端進行交互(現(xiàn)階段還無法完全實現(xiàn))；如果采用“客戶端直接抽取字節(jié)范圍”的技術方案，那么“懂媒體片段的”(即:能解析并解釋媒體片段URI并支持特定的媒體編解碼格式的)客戶端可通過傳統(tǒng)HTTP協(xié)議與傳統(tǒng)服務端進行交互來進行處理(這是現(xiàn)階段較現(xiàn)實的可行技術方案，但現(xiàn)有技術尚未給出完整的解決方法)。不管采用以上何種技術方案，由于“URI片段”定址方式要求媒體片段的抽取無需轉(zhuǎn)碼操作，而直接將片段URI映射(mapping)為主資源的字節(jié)范圍(如:10-20秒的時間片段對應于3000 - 6000字節(jié)范圍)，因此對媒體格式有特定要求:①對時間片段:需要隨機存取點以常規(guī)方式出現(xiàn)，以便保持字節(jié)等同性(byte-1dentity)，目前大多數(shù)媒體(容器)格式能滿足此要求；②對空間片段:需要獨立編碼的空間區(qū)域，如興趣區(qū)域(ROIs)與背景是獨立編碼的，目前大多數(shù)媒體(容器)格式無法滿足此要求(因此空間片段的定址只能采用“URI查詢”方式)。以上情況說明，盡管W3C的《媒體片段URI 1.0 (基本)標準》涵蓋了時間片段和空間片段的“URI查詢”及“URI片段”定址方式，但是，現(xiàn)階段在這個領域的技術研發(fā)主要集中在針對時間片段的“URI片段”定址方式上。
[0008]W3C的《媒體片段URI 1.0 (基本)標準》中，時間片段在HTTP協(xié)議下的“URI片段”定址方式的標準語法格式為:
[0009]http: //<主機 > [:端口]〈絕對路徑>#<片段定址>[0010]其中:“http://〈主機 >[:端口 ]〈絕對路徑〉”部分用于標識主資源；“ #〈片段定址 >”部分用于表示一個時間片段的定址參數(shù)，它采用特定的名-值對來表示:名用t表示，值用開始時間和結(jié)束時間(如視頻編輯中的入點和出點)界定的半開時間間隔(timeinterval)來表示，開始時間(省略時默認為O秒)和結(jié)束時間(省略時默認為整個主資源的結(jié)束時間點)之間用逗號分隔，可選的時間單位包括:Normal Play Time (npt:)(此為默認單位)、SMPTE (smpte:)、現(xiàn)實世界時鐘時間(clock:),例如:t=npt: 10，20表示時間間隔[10, 20) ;t=，2 表示時間間隔[0,20) ;t=smpte:0:02:00 表示時間間隔[120，end)。
[0011]根據(jù)以上語法格式，以下時間片段URI:
[0012]http://www.example, org/vide0.mp4#t=npt:68, 120
[0013]解釋為:由“http://www.example, org/vide0.mp4” 這個 URI 標識的主資源(一個MP4容器格式的媒體資源,其文件名為video, mp4)中，以Normal Play Time為單位的時間間隔為[68，120)的媒體片段(即主資源中第68秒開始一直延續(xù)到第120秒結(jié)束的部分)。
[0014]W3C的《媒體片段URI 1.0 (基本)標準》把媒體片段定義為“時間上線性的(time-linear)”,其特點是具有單一的時間軸。容器(container)格式的媒體資源通常包含沿著統(tǒng)一時間軸平行的多個軌的數(shù)據(jù)，例如視頻(video)、音頻(audio)、圖像(images)及文本(text)等。每個軌的媒體資源有一個包含控制信息的數(shù)據(jù)頭(data header),整個媒體資源通常有一個一般頭(general header)0為了能漸進解碼，不同數(shù)據(jù)軌一般以交錯方式編碼。所有這一切都封裝在一個單一的容器文件中。一些支持全索引(full index)的容器格式(如:MP4、AV1、0gg等)的頭信息中包含了時間到字節(jié)位移(byte-offset)的映射關系，因此能籍此實現(xiàn)媒體片段的時間間隔到主資源字節(jié)范圍的映射，也就能較為簡單地實現(xiàn)從主資源文件中抽取一個時間片段作為次生資源。
[0015]媒體片段在Web上具有廣泛用途，W3C媒體片段工作組起草的《媒體片段用例與需求(草案)》(參見 “R.Troncy, E.Mannens (Editors)，Jansen J, Lafon Y, PfeifferS，Van Deursen D(Contributors).Use cases and requirements for MediaFragments[R/0L].W3C Working Draft, 17 December 2009.http://www.w3.0rg/TR/2009/ffD-media-frags-reas-20091217.，，)中列舉了媒體片段的實際用例，包括:片段的鏈接、顯示或播放、瀏覽和置書簽、重新合成、標注，以及媒體資源的改編等。
[0016]關于本領域的相關技術現(xiàn)狀，國際上當前主要處在《媒體片段URI 1.0 (基本)標準》的制訂以及該標準在Web上(尤其是在HTTP協(xié)議下)【具體實施方式】方法的討論階段。W3C媒體片段工作組成員公開發(fā)表在國際學術期刊《多媒體工具與應用》的相關論文中(參見 “Van Lancker W，Van Deursen D, Mannens E, Van de Walle R.1mplementationstrategies for efficient media fragment retrieval[J].Multimedia Tools andApplications, March 2012, 57(2):243-267.”)討論并比較了媒體片段HTTP檢索的幾種可能的實現(xiàn)策略，得出的結(jié)論是:①已有研究主要集中在探討如何將服務端(媒體服務器或代理服務器)按擴充的HTTP協(xié)議升級改造為“懂媒體片段的”服務端(如:作為URI 1.0概念證明的NinSuna服務器)，或如何開發(fā)媒體片段的(第三方)翻譯服務器(如:作為URI 1.0概念證明的MFTS翻譯服務設想);②目前尚沒有能通過傳統(tǒng)HTTP協(xié)議與傳統(tǒng)服務端進行交互來處理媒體片段URI的“懂媒體片段的”客戶端實現(xiàn)。
[0017]最近，一些部分支持HTML5 候選標準(參見 “Berjon R, Faulkner S，LeitheadT,Doyle Navara Ε，0' Connor Ε, Pfeiffer S，Hickson I(Editors).HTML5: A vocabularyand associated APIs for HTML and XHTML[R/OL].W3C Candidate Recommendation, 6August 2013:http://www.w3.0rg/TR/2013/CR-html5-20130806/.”)的最新版瀏覽器(如:Mozilla Firefox和Google Chrome等)能部分支持媒體片段URI1.0標識的時間片段的在線播放，其不足之處是僅部分支持時間片段URI1.0語法，且只能在瀏覽器中對時間片段進行在線播放，而不能讓客戶端抽取并獲得時間片段資源文件，因此無法進一步支持實現(xiàn)W3C《媒體片段用例與需求(草案)》中所要求的多種片段實際用例，包括:片段的鏈接、瀏覽和置書簽、重新合成、標注，以及媒體資源的改編等。
[0018]中國專利號CN 101577627 B，
【公開日】2011年9月9日，授權(quán)公告日2011年12月14日，發(fā)明創(chuàng)造的名稱為“多媒體文件的下載播放系統(tǒng)及方法”，該已授權(quán)發(fā)明專利公開了一種多媒體文件的下載播放系統(tǒng)及方法，其所述方法包括:下載多媒體文件的頭部信息；解析頭部信息，并根據(jù)頭部信息獲取多媒體數(shù)據(jù)的下載位置信息；根據(jù)下載位置信息下載多媒體數(shù)據(jù)以及播放下載的多媒體數(shù)據(jù)。該發(fā)明專利技術方案的主要缺陷包括:完全不支持W3C的《媒體片段URI 1.0 (基本)標準》；只能在線播放多媒體文件，無法使客戶端獲取時間片段資源文件；客戶端與服務端之間以及客戶端的播放單元與下載單元之間需要不斷進行復雜的交互；只宏觀上描述了下載、解析多媒體文件頭部信息并據(jù)此獲取多媒體數(shù)據(jù)下載位置的步驟(不足以說明其技術方案針對各種多媒體格式的可實施性與實用性)，特別地，未具體描述針對全索引容器格式媒體資源時間片段的技術方案，也未具體給出相應的HTTP請求/響應協(xié)議步驟。
[0019]因此，本發(fā)明要解決的技術問題是針對符合W3C媒體片段URI 1.0標準的全索引容器格式媒體資源的時間片段，有必要提出一種無需改造現(xiàn)有的媒體服務器和無需擴充HTTP協(xié)議，而由客戶端通過傳統(tǒng)HTTP協(xié)議來檢索并獲取時間片段文件的方法，以避免對當前Web基礎設施的改造，并且比下載完整媒體資源的傳統(tǒng)技術方案大大節(jié)省通信帶寬和縮短通信延時。

【發(fā)明內(nèi)容】

[0020]本發(fā)明的目的旨在提供一種客戶端的媒體資源時間片段的檢索方法，無需改造現(xiàn)有的媒體服務器和無需擴充HTTP協(xié)議，而由客戶端通過傳統(tǒng)HTTP協(xié)議來檢索并獲取時間片段文件的方法，以避免對當前Web基礎設施的改造，并且比下載完整媒體資源的傳統(tǒng)技術方案大大節(jié)省通信帶寬和縮短通信延時。
[0021]本發(fā)明提出一種客戶端HTTP檢索全索引容器格式媒體資源時間片段的方法，包括:SI，解析媒體片段URI，獲得主資源URI及片段的時間間隔；S2，判斷片段是否已在本地HTTP緩存中:若是則執(zhí)行步驟S3，否則執(zhí)行步驟S5 ;S3，判斷服務端是否已更新片段的主資源:若是則執(zhí)行步驟S5，否則執(zhí)行步驟S4 ；S4,從本地HTTP緩存中獲得片段資源文件，處理結(jié)束；S5，向服務端請求并獲得主資源的頭信息；S6，將片段的時間間隔映射為主資源的字節(jié)范圍；S7，向服務端請求并獲得字節(jié)范圍；S8，修改頭信息，并與字節(jié)范圍合成為片段資源文件。
[0022]本發(fā)明提出的一種媒體資源時間片段的客戶端檢索方法，能夠支持W3C媒體片段URI 1.0標準，由客戶端完成時間片段URI向媒體資源字節(jié)范圍映射并從傳統(tǒng)服務端獲取字節(jié)范圍后生成媒體片段文件，從而無需改造現(xiàn)有的媒體服務器和無需擴充HTTP協(xié)議，而由客戶端通過傳統(tǒng)HTTP協(xié)議來檢索并獲取時間片段文件的方法，以避免對當前Web基礎設施的改造，并且比下載完整媒體資源的傳統(tǒng)技術方案大大節(jié)省通信帶寬和縮短通信延時。
[0023]本發(fā)明附加的方面和優(yōu)點將在下面的描述中部分給出，這些將從下面的描述中變得明顯，或通過本發(fā)明的實踐了解到。
【專利附圖】

【附圖說明】
[0024]圖1示出了根據(jù)本發(fā)明技術方案的客戶端HTTP檢索全索引容器格式媒體資源時間片段的方法的流程示意圖；
[0025]圖2示出了根據(jù)本發(fā)明技術方案的客戶端HTTP檢索全索引容器格式媒體資源時間片段的處理過程中與服務端進行HTTP通信的方法的流程示意圖；
[0026]圖3示出了根據(jù)本發(fā)明技術方案的客戶端解析媒體片段URI并獲得主資源URI及片段的時間間隔的流程示意圖；
[0027]圖4示出了根據(jù)本發(fā)明技術方案的客戶端將媒體片段的時間間隔映射為主資源的字節(jié)范圍的流程示意圖。
【具體實施方式】
[0028]下面詳細描述本發(fā)明的實施方式，所述實施方式的示例在附圖中示出，其中自始至終相同或類似的標號表示相同或類似的概念、對象、要素等或具有相同或類似功能的概念、對象、要素等。下面通過參考附圖描述的實施方式是示例性的，僅用于解釋本發(fā)明，而不能解釋為對本發(fā)明的限制。
[0029]本【技術領域】技術人員可以理解，除非另外定義，這里使用的所有術語(包括技術術語和科學術語)具有與本發(fā)明所屬領域中的普通技術人員的一般理解相同的意義。還應該理解的是，諸如通用字典中定義的那些術語應該被理解為具有與現(xiàn)有技術的上下文中的意義一致的意義，并且除非像這里一樣定義，不會用理想化或過于正式的含義來解釋。
[0030]圖1示出了根據(jù)本發(fā)明技術方案的客戶端HTTP檢索全索引容器格式媒體資源時間片段的方法的流程示意圖。如圖1所示，本發(fā)明提出一種客戶端HTTP檢索全索引容器格式媒體資源時間片段的方法，包括:S1，解析媒體片段URI，獲得主資源URI及片段的時間間隔；S2，判斷片段是否已在本地HTTP緩存中:若是則執(zhí)行步驟S3，否則執(zhí)行步驟S5 ;S3，判斷服務端是否已更新片段的主資源:若是則執(zhí)行步驟S5，否則執(zhí)行步驟S4 ;S4，從本地HTTP緩存中獲得片段資源文件，處理結(jié)束；S5，向服務端請求并獲得主資源的頭信息；S6，將片段的時間間隔映射為主資源的字節(jié)范圍；S7，向服務端請求并獲得字節(jié)范圍；S8，修改頭信息，并與字節(jié)范圍合成為片段資源文件。
[0031]進一步地，解析媒體片段URI，獲得主資源URI及片段的時間間隔，包括:以片段URI中的“#”為分割點獲取主資源URI部分和片段定址部分；判斷主資源URI部分是否符合RFC-3986 URI語法，若否，則報錯并終止；判斷片段定址部分是否符合媒體片段URI 1.0語法，若否，則報錯并終止；根據(jù)時間單位計算出以秒為計的開始時間與結(jié)束時間；判斷開始時間是否小于結(jié)束時間，若否，則報錯并終止；根據(jù)以秒為計的開始時間與結(jié)束時間計算出時間間隔。[0032]進一步地，判斷服務端是否已更新片段的主資源，包括:客戶端向服務端發(fā)送一個HTTP If-Modified-Since條件GET請求；客戶端收到服務端的狀態(tài)碼響應后，根據(jù)狀態(tài)碼進行判斷:若狀態(tài)碼為HTTP 304 Not Modified則表示服務端未更新片段的主資源，若狀態(tài)碼為HTTP 412 Precondition Failed則表示服務端已更新片段的主資源。
[0033]進一步地，向服務端請求并獲得主資源的頭信息，包括:根據(jù)主資源文件名的后綴名確定具體的容器格式；根據(jù)該容器格式確定頭信息的位置與字節(jié)大小，由此確定主資源的頭信息在該媒體資源中的字節(jié)范圍；向服務端發(fā)送HTTP字節(jié)范圍GET請求；接收服務端返回的HTTP 206 Partial Content狀態(tài)碼響應及該響應中所含的頭信息二進制數(shù)據(jù)。
[0034]進一步地，將片段的時間間隔映射為主資源的字節(jié)范圍，包括:按容器格式的頭信息數(shù)據(jù)結(jié)構(gòu)從主資源頭信息的二進制數(shù)據(jù)中提取信息；將片段時間間隔轉(zhuǎn)換為媒體時間坐標系統(tǒng)中的時間間隔；在頭信息數(shù)據(jù)結(jié)構(gòu)中查找到時間間隔所對應的樣本序號；在頭信息數(shù)據(jù)結(jié)構(gòu)中查找到與樣本序號最接近的關鍵幀序號；在頭信息數(shù)據(jù)結(jié)構(gòu)中查找到最接近關鍵幀在主資源文件中的字節(jié)位移，據(jù)此計算出字節(jié)范圍。
[0035]進一步地，向服務端請求并獲得字節(jié)范圍，包括:向服務端發(fā)送HTTP字節(jié)范圍GET請求；接收服務端返回的HTTP 206 Partial Content狀態(tài)碼響應及該響應中所含的字節(jié)范圍二進制數(shù)據(jù)。
[0036]進一步地，修改頭信息，并與字節(jié)范圍合成為片段資源文件，包括:修改主資源文件的頭信息二進制數(shù)據(jù)；將修改后的頭信息二進制數(shù)據(jù)與字節(jié)范圍二進制數(shù)據(jù)合成為片段資源文件。
[0037]本發(fā)明提出的一種客戶端的媒體資源時間片段的檢索方法，能夠支持W3C媒體片段URI 1.0標準，由客戶端完成時間片段URI向媒體資源字節(jié)范圍映射并從傳統(tǒng)服務端獲取字節(jié)范圍后生成媒體片段文件，從而無需改造現(xiàn)有的媒體服務器和無需擴充HTTP協(xié)議，而由客戶端通過傳統(tǒng)HTTP協(xié)議來檢索并獲取時間片段文件的方法，以避免對當前Web基礎設施的改造，并且比下載完整媒體資源的傳統(tǒng)技術方案大大節(jié)省通信帶寬和縮短通信延時。
[0038]下文將對上述各步驟具體展開描述。為便于理解，如下表I中列出了相關步驟中客戶端與服務端進行HTTP通信時使用的HTTP請求/響應中包含的主要術語及其含義:
[0039]表1:本發(fā)明技術方案使用的HTTP請求/響應中包含的主要術語及其含義
[0040]
【權(quán)利要求】
1.一種客戶端HTTP檢索全索引容器格式媒體資源時間片段的方法，其特征在于，包括: SI，解析媒體片段URI，獲得主資源URI及片段的時間間隔； S2，判斷片段是否已在本地HTTP緩存中:若是則執(zhí)行步驟S3，否則執(zhí)行步驟S5 ； S3，判斷服務端是否已更新片段的主資源:若是則執(zhí)行步驟S5，否則執(zhí)行步驟S4 ； S4,從本地HTTP緩存中獲得片段資源文件，處理結(jié)束； S5，向服務端請求并獲得主資源的頭信息； S6，將片段的時間間隔映射為主資源的字節(jié)范圍； S7，向服務端請求并獲得字節(jié)范圍； S8，修改頭信息，并與字節(jié)范圍合成為片段資源文件。
2.如權(quán)利要求1所述的客戶端HTTP檢索全索引容器格式媒體資源時間片段的方法,其特征在于，解析媒體片段URI，獲得主資源URI及片段的時間間隔，包括: 以片段URI中的“#”為分割點獲取主資源URI部分和片段定址部分； 判斷主資源URI部分是否符合RFC-3986URI語法，若否，則報錯并終止； 判斷片段定址部分是否符合媒體片段URI 1.0語法，若否，則報錯并終止； 根據(jù)時間單位計算出以秒為計的開始時間與結(jié)束時間； 判斷開始時間是否小于結(jié)束時間，若否，則報錯并終止； 根據(jù)以秒為計的開始時間與結(jié)束時間計算出時間間隔。
3.如權(quán)利要求1所述的客戶端HTTP檢索全索引容器格式媒體資源時間片段的方法,其特征在于，判斷服務端是否已更新片段的主資源，包括: 向服務端發(fā)送一個HTTP If-Modified-Since條件GET請求； 收到服務端的狀態(tài)碼響應后，根據(jù)狀態(tài)碼進行判斷:若狀態(tài)碼為HTTP 304 NotModified則表示服務端未更新片段的主資源,若狀態(tài)碼為HTTP 412 Precondition Failed則表示服務端已更新片段的主資源。
4.如權(quán)利要求1所述的客戶端HTTP檢索全索引容器格式媒體資源時間片段的方法,其特征在于，向服務端請求并獲得主資源的頭信息，包括: 根據(jù)主資源文件名的后綴名確定具體的容器格式； 根據(jù)該容器格式確定頭信息的位置與字節(jié)大小，由此確定主資源的頭信息在該媒體資源中的字節(jié)范圍； 向服務端發(fā)送HTTP字節(jié)范圍GET請求； 接收服務端返回的HTTP 206 Partial Content狀態(tài)碼響應及該響應中所含的頭信息二進制數(shù)據(jù)。
5.如權(quán)利要求1所述的客戶端HTTP檢索全索引容器格式媒體資源時間片段的方法,其特征在于，將片段的時間間隔映射為主資源的字節(jié)范圍，包括: 按容器格式的頭信息數(shù)據(jù)結(jié)構(gòu)從主資源頭信息的二進制數(shù)據(jù)中提取信息； 將片段時間間隔轉(zhuǎn)換為媒體時間坐標系統(tǒng)中的時間間隔； 在頭信息數(shù)據(jù)結(jié)構(gòu)中查找到時間間隔所對應的樣本序號； 在頭信息數(shù)據(jù)結(jié)構(gòu)中查找到與樣本序號最接近的關鍵幀序號； 在頭信息數(shù)據(jù)結(jié)構(gòu)中查找到最接近關鍵幀在主資源文件中的字節(jié)位移，據(jù)此計算出字節(jié)范圍。
6.如權(quán)利要求1所述的客戶端HTTP檢索全索引容器格式媒體資源時間片段的方法,其特征在于，向服務端請求并獲得字節(jié)范圍，包括: 向服務端發(fā)送HTTP字節(jié)范圍GET請求； 接收服務端返回的HTTP 206 Partial Content狀態(tài)碼響應及該響應中所含的字節(jié)范圍二進制數(shù)據(jù)。
7.如權(quán)利要求1所述的客戶端HTTP檢索全索引容器格式媒體資源時間片段的方法,其特征在于，修改頭信息，并與字節(jié)范圍合成為片段資源文件，包括: 修改主資源文件的頭信息二進制數(shù)據(jù)； 將修改后的頭信息二進制數(shù)據(jù)與字節(jié)范圍 二進制數(shù)據(jù)合成為片段資源文件。
【文檔編號】G06F17/30GK103747065SQ201310738843
【公開日】2014年4月23日 申請日期:2013年12月27日 優(yōu)先權(quán)日:2013年12月27日
【發(fā)明者】許卓明, 吳婷, 倪立顯, 何文潔, 莊遠航, 王駿華, 仵莉莉 申請人:河海大學