本申請(qǐng)一般地涉及傳輸系統(tǒng)中的媒體數(shù)據(jù)傳遞，并且更具體地，涉及基于推送的、自適應(yīng)的超文本傳輸協(xié)議(HTTP)流。

背景技術(shù)：

傳統(tǒng)地，傳輸控制協(xié)議(TCP)已經(jīng)被認(rèn)為不適合諸如音頻和視頻內(nèi)容的實(shí)時(shí)媒體的傳遞。這主要是由于TCP實(shí)施的激進(jìn)的擁塞控制算法和重傳程序所致。TCP中，發(fā)送者在檢測(cè)到擁塞事件——一般通過丟包或過度的傳輸延遲來識(shí)別時(shí)，顯著地降低傳輸速率(通常降低到一半)。因而，TCP的傳輸吞吐量通常以公知的鋸齒形狀為特征。這一行為對(duì)流應(yīng)用(streaming application)是不利的，因?yàn)樗鼈儗?duì)延遲敏感但相對(duì)能容忍丟包，然而TCP犧牲傳遞延遲以利于可靠的并且可感知阻塞(congestion-aware)的傳輸。

技術(shù)實(shí)現(xiàn)要素：

[技術(shù)問題]

近來，趨勢(shì)已經(jīng)轉(zhuǎn)向部署作為用于通過互聯(lián)網(wǎng)傳遞多媒體內(nèi)容的首選協(xié)議的超文本傳輸協(xié)議(HTTP)。HTTP在TCP的上面運(yùn)行并且是文本協(xié)議。這一轉(zhuǎn)變的原因在于該協(xié)議容易部署。不需要部署用于傳遞內(nèi)容的專用服務(wù)器。而且，HTTP通常被準(zhǔn)許經(jīng)防火墻和NAT進(jìn)行訪問，其顯著地簡(jiǎn)化了部署。

[問題的解決方案]

在第一實(shí)施例中，提供了一種設(shè)備。該設(shè)備包括：天線，被配置為建立與服務(wù)器的通信連接。該設(shè)備還包括處理電路，被配置為：對(duì)服務(wù)器支持網(wǎng)絡(luò)套接字WebSocket上的自適應(yīng)的超文本傳輸協(xié)議(HTTP)流的能力進(jìn)行確定；為在HTTP流期間執(zhí)行速率自適應(yīng)操作而向服務(wù)器發(fā)送命令；以及在HTTP流上接收來自服務(wù)器的信息。

在第二實(shí)施例中，提供了一種服務(wù)器。該服務(wù)器包括被配置為耦接到至少一個(gè)客戶端設(shè)備的接口。該服務(wù)器還包括處理電路，被配置為：向至少一個(gè)客戶端設(shè)備發(fā)送關(guān)于支持WebSocket上的自適應(yīng)的超文本傳輸協(xié)議(HTTP)流的指示；接收升級(jí)的請(qǐng)求、確定是接受還是拒絕該升級(jí)，并且響應(yīng)于從至少一個(gè)客戶端設(shè)備接收的、在HTTP流期間進(jìn)行流操作的命令，建立與至少一個(gè)客戶端設(shè)備的傳入的WebSocket連接。

第三實(shí)施例中，提供了一種用于客戶端設(shè)備的方法。該方法包括建立與服務(wù)器的通信連接。該方法還包括對(duì)服務(wù)器支持WebSocket上的自適應(yīng)的超文本傳輸協(xié)議(HTTP)流的能力的確定。該方法進(jìn)一步包括為了在HTTP流期間執(zhí)行流操作而向服務(wù)器發(fā)送命令。

從以下特征、描述和權(quán)利要求中，其它的技術(shù)特征對(duì)本領(lǐng)域技術(shù)人員可以是容易顯見的。

在進(jìn)行以下具體描述之前，闡述貫穿本專利文檔全文所使用的某些詞語和短語的定義可能是有益的。術(shù)語“耦接”及其衍生詞指代兩個(gè)或多個(gè)元件之間的任意直接或非直接的通信，無論那些元件是否彼此物理接觸。術(shù)語“發(fā)送”、“接收”和“通信”及其衍生詞，包括直接和非直接的通信兩者。術(shù)語“包括”和“包含”及其衍生詞，意思是無限制的包括。術(shù)語“或”是包括性的，意思是和/或。短語“與…關(guān)聯(lián)”及其衍生詞，意思是包括、包括在內(nèi)、與…互連、包含、包含在內(nèi)、連接到或與…連接、耦接到或與…耦接、與…通信、與…合作、交織、并列、靠近、與…緊密相連、具有、具有…屬性、與…有關(guān)系等。術(shù)語“控制器”指的是控制至少一個(gè)操作的任意設(shè)備、系統(tǒng)或其部分。這樣的控制器可在硬件或硬件和軟件的組合和/或固件中實(shí)現(xiàn)。與任意特定控制器關(guān)聯(lián)的功能可以被集中或分布，無論在本地或遠(yuǎn)端地。短語“至少其一”，當(dāng)和列表項(xiàng)使用時(shí)，意思是一個(gè)或多個(gè)所列項(xiàng)目的不同組合可以被使用，并且可能只需要列表中的一個(gè)項(xiàng)目。例如，“A、B和C中至少一個(gè)”包括任意以下組合：A、B、C、A和B、A和C、B和C，以及A和B和C。

并且，以下描述的各種功能可由一個(gè)或多個(gè)計(jì)算機(jī)程序?qū)崿F(xiàn)或支持，每個(gè)計(jì)算機(jī)程序由計(jì)算機(jī)可讀程序代碼形成并且在計(jì)算機(jī)可讀介質(zhì)中具體化。術(shù)語“應(yīng)用”和“程序”指的是一個(gè)或多個(gè)計(jì)算機(jī)程序、軟件組件、指令集、過程、功能、對(duì)象、類、實(shí)例、相關(guān)的數(shù)據(jù)及改變以適合在合適的計(jì)算機(jī)可讀程序代碼中實(shí)現(xiàn)的其部分。短語“計(jì)算機(jī)可讀程序代碼”包括任意類型計(jì)算機(jī)代碼，包括源代碼、目標(biāo)代碼和可執(zhí)行代碼。短語“計(jì)算機(jī)可讀介質(zhì)”包括能被計(jì)算機(jī)訪問的任意類型介質(zhì)，諸如只讀存儲(chǔ)器(ROM)、隨機(jī)存取存儲(chǔ)器(RAM)、硬盤驅(qū)動(dòng)器、致密盤(CD)、數(shù)字視頻盤(DVD)或任何其它類型存儲(chǔ)器。“非暫態(tài)”計(jì)算機(jī)可讀介質(zhì)不包括傳輸暫時(shí)的電的或其它信號(hào)的有線的、無線的、光學(xué)的或其它通信鏈路。非暫態(tài)計(jì)算機(jī)可讀介質(zhì)包括數(shù)據(jù)可以被永久地存儲(chǔ)的介質(zhì)和數(shù)據(jù)可以被存儲(chǔ)并且之后被重寫的介質(zhì)，諸如可再寫光盤或可擦除存儲(chǔ)器設(shè)備。

貫穿本專利文檔全文提供了對(duì)于其它某些詞語和短語的定義。本領(lǐng)域技術(shù)人員應(yīng)當(dāng)明白，在許多情況而非大多數(shù)情況下，這些定義適用于這樣定義的詞語和短語的現(xiàn)有的和將來的使用。

附圖說明

為了對(duì)本公開及其優(yōu)點(diǎn)的更全面理解，結(jié)合附圖，對(duì)以下描述進(jìn)行了引用，其中相同的附圖標(biāo)記指代相同的部分：

圖1示出了根據(jù)本公開的示例計(jì)算系統(tǒng)；

圖2和圖3示出了根據(jù)本公開的計(jì)算系統(tǒng)中的示例設(shè)備；

圖4示出了根據(jù)本公開的實(shí)施例的自適應(yīng)的HTTP流架構(gòu)；

圖5示出了根據(jù)本公開的實(shí)施例的MPD結(jié)構(gòu)；

圖6和圖7示出了根據(jù)本公開的HTTP 1.0和HTTP 2.0之間的區(qū)別；

圖8示出了根據(jù)本公開的實(shí)施例的支持WebSocket(網(wǎng)絡(luò)套接字)的網(wǎng)絡(luò)；

圖9示出了根據(jù)本公開的實(shí)施例的對(duì)客戶端設(shè)備使用WebSocket的自適應(yīng)的HTTP流過程；以及

圖10示出了根據(jù)本公開的實(shí)施例的對(duì)服務(wù)器使用WebSocket的自適應(yīng)的HTTP流過程。

具體實(shí)施方式

以下所討論的圖1到圖10，和用來描述本專利文檔中的發(fā)明的原理的各種實(shí)施例只作為闡述并且不應(yīng)被以任何方式解釋為限制本公開的范圍。本領(lǐng)域技術(shù)人員應(yīng)當(dāng)理解本公開的原理可在任何適當(dāng)安排的設(shè)備或系統(tǒng)中實(shí)現(xiàn)。

圖1示出了根據(jù)本公開的示例計(jì)算系統(tǒng)100。圖1所示的計(jì)算系統(tǒng)100的實(shí)施例只是用于闡述。計(jì)算系統(tǒng)100的其它實(shí)施例可以在不脫離本公開范圍的情況下使用。

如圖1所示，系統(tǒng)100包括有助于系統(tǒng)100中各種組件之間的通信的網(wǎng)絡(luò)102。例如，網(wǎng)絡(luò)102可以在網(wǎng)絡(luò)地址之間傳送網(wǎng)際協(xié)議(IP)包、幀中繼幀、異步傳輸模式(ATM)信元，或其它信息。網(wǎng)絡(luò)102可以包括一個(gè)或多個(gè)局域網(wǎng)(LAN)、城域網(wǎng)(MAN)、廣域網(wǎng)(WAN)、諸如互聯(lián)網(wǎng)的全球網(wǎng)絡(luò)的全部或部分、或一個(gè)或多個(gè)位置處的任何其它通信系統(tǒng)。

網(wǎng)絡(luò)102有助于至少一個(gè)服務(wù)器104和各種客戶端設(shè)備106-114之間的通信。每個(gè)服務(wù)器104包括可以對(duì)一個(gè)或多個(gè)客戶端設(shè)備提供計(jì)算服務(wù)的任何合適的計(jì)算或處理設(shè)備。每個(gè)服務(wù)器104可以包括，例如，一個(gè)或多個(gè)處理設(shè)備、存儲(chǔ)指令和數(shù)據(jù)的一個(gè)或多個(gè)存儲(chǔ)器、以及有助于通過網(wǎng)絡(luò)102的通信的一個(gè)或多個(gè)網(wǎng)絡(luò)接口。

每個(gè)客戶端設(shè)備106-114表示通過網(wǎng)絡(luò)102與至少一個(gè)服務(wù)器或其它(多個(gè))計(jì)算設(shè)備交互的任何合適的計(jì)算或處理設(shè)備。在這一示例中，客戶端設(shè)備106-114包括桌面型計(jì)算機(jī)106、移動(dòng)電話或智能電話108、個(gè)人數(shù)字助手(PDA)110、膝上型計(jì)算機(jī)112、以及平板計(jì)算機(jī)114。然而，任何其它或附加的客戶端設(shè)備可在計(jì)算系統(tǒng)100中使用。

在這個(gè)示例中，一些客戶端設(shè)備108-114與網(wǎng)絡(luò)102間接地通信。例如，客戶端設(shè)備108-110經(jīng)諸如蜂窩基站或eNodeB的一個(gè)或多個(gè)基站116通信。并且，客戶端設(shè)備112-114經(jīng)諸如IEEE 802.11無線接入點(diǎn)的一個(gè)或多個(gè)無線接入點(diǎn)118通信。注意，這些只是用于闡述并且每個(gè)客戶端設(shè)備可以與網(wǎng)絡(luò)102直接地通信或者經(jīng)任意(多個(gè))合適的中間設(shè)備或網(wǎng)絡(luò)與網(wǎng)絡(luò)102間接地通信。

如以下更具體描述的，網(wǎng)絡(luò)102有助于HTTP上的高效的、基于推送的媒體流。一個(gè)或多個(gè)服務(wù)器104支持通過WebSocket(網(wǎng)絡(luò)套接字)的媒體流。當(dāng)服務(wù)器104支持通過WebSocket的媒體流時(shí)，一個(gè)或多個(gè)客戶端設(shè)備106-114能夠檢測(cè)到。當(dāng)服務(wù)器104支持通過WebSocket的媒體流時(shí)，一個(gè)或多個(gè)客戶端設(shè)備106-114能夠建立到服務(wù)器的WebSocket連接并且提交指示流中所選擇的再現(xiàn)(representation)和位置的初始請(qǐng)求。各個(gè)客戶端設(shè)備106-114然后按照服務(wù)器104所推送的順序來接收媒體分段(segment)。

盡管圖1示出了計(jì)算系統(tǒng)100的一個(gè)示例，但是可以對(duì)圖1進(jìn)行各種變化。例如，系統(tǒng)100可以以任何適當(dāng)?shù)牟贾冒ㄈ我鈹?shù)目的每個(gè)組件。通常，計(jì)算和通信系統(tǒng)以多種配置出現(xiàn)，并且圖1不將本公開的范圍限制為任何特定配置。盡管圖1示出了其中本專利文檔所公開的各種特征可以被使用的一種操作環(huán)境，但是這些特征可以在任何其它合適的系統(tǒng)中使用。

圖2和圖3示出了根據(jù)本公開的計(jì)算系統(tǒng)中的示例設(shè)備。特別地，圖2示出了示例服務(wù)器200，并且圖3示出了示例客戶端設(shè)備300。服務(wù)器200可以表示圖1中的服務(wù)器104，并且客戶端設(shè)備300可以表示圖1中的客戶端設(shè)備106-114的一個(gè)或多個(gè)。

如圖2所示，服務(wù)器200包括總線系統(tǒng)205，其支持至少一個(gè)處理設(shè)備210、至少一個(gè)存儲(chǔ)設(shè)備215、至少一個(gè)通信單元220和至少一個(gè)輸入/輸出(I/O)單元225之間的通信。服務(wù)器104可以被配置為與服務(wù)器200相同或類似。服務(wù)器200能夠支持通過WebSocket的媒體流。

處理設(shè)備210運(yùn)行可以被加載到存儲(chǔ)器230中的指令。處理設(shè)備210可以以任何適當(dāng)?shù)牟贾冒ㄈ魏芜m當(dāng)數(shù)目和類型的處理器或其它設(shè)備。處理設(shè)備210的示例類型可以包括微處理器、微控制器、數(shù)字信號(hào)處理器、現(xiàn)場(chǎng)可編程門陣列、專用集成電路和分立電路。

存儲(chǔ)器230和持久的存儲(chǔ)裝置235是存儲(chǔ)設(shè)備215的示例，其表示能夠存儲(chǔ)并且有助于信息(諸如臨時(shí)或永久的數(shù)據(jù)、程序代碼和/或其它合適的信息)的取回的任意結(jié)構(gòu)。存儲(chǔ)器230可以表示隨機(jī)存取存儲(chǔ)器或任何其它合適的(多個(gè))易失性或非易失性存儲(chǔ)設(shè)備。持久的存儲(chǔ)裝置235可以包含支持較長(zhǎng)期的數(shù)據(jù)存儲(chǔ)的一個(gè)或多個(gè)組件或設(shè)備，諸如只讀存儲(chǔ)器、硬盤驅(qū)動(dòng)器、快閃存儲(chǔ)器或光盤。

通信單元220支持與其它系統(tǒng)或設(shè)備的通信。例如，通信單元220可以包括有助于通過網(wǎng)絡(luò)102的通信的處理電路、網(wǎng)絡(luò)接口卡或無線收發(fā)機(jī)。通信單元220可以支持經(jīng)任何合適的(多個(gè))物理的或無線的通信鏈路的通信。通信單元220使能到一個(gè)或多個(gè)客戶端設(shè)備的連接。即，通信單元220提供被配置為耦接到至少一個(gè)客戶端設(shè)備的接口。

I/O單元225允許數(shù)據(jù)的輸入和輸出。例如，I/O單元225可以提供用于經(jīng)鍵盤、鼠標(biāo)、鍵區(qū)、觸摸屏或其它合適的輸入設(shè)備的用戶輸入的連接。I/O單元225還可以將輸出發(fā)送到顯示器、打印機(jī)或其它合適的輸出設(shè)備。

注意，盡管圖2被描述為表示圖1的服務(wù)器104，但是相同或相似的結(jié)構(gòu)可以在一個(gè)或多個(gè)客戶端設(shè)備106-114中使用。例如，膝上型或桌面型計(jì)算機(jī)可以具有和圖2中所示的相同或相似的結(jié)構(gòu)。

圖3示出了根據(jù)本公開的示例STA 300。圖2中示出的STA 300的實(shí)施例只是用于闡述，并且圖1的(多個(gè))STA 104-112可以具有相同或相似的配置。然而，(多個(gè))STA以多種配置出現(xiàn)，并且圖3不將本公開的范圍限制為STA的任何特定的實(shí)施方式。

STA 300包括多個(gè)天線305a-305n、多個(gè)無線電頻率(RF)收發(fā)機(jī)310a-310n、發(fā)送(TX)處理電路315、麥克風(fēng)320和接收(RX)處理電路325。TX處理電路315和RX處理電路325分別耦接到每個(gè)RF收發(fā)機(jī)310a-310n，例如，耦接到RF收發(fā)機(jī)310a、RF收發(fā)機(jī)310b直到第N個(gè)RF收發(fā)機(jī)310n，這些RF收發(fā)機(jī)分別耦接到天線305a、天線305b和第N條天線305n。在某些實(shí)施例中，STA 104包括單一的天線305a和單一的RF收發(fā)機(jī)310a。STA 300還包括揚(yáng)聲器330、主處理器340、輸入/輸出(I/O)接口(IF)345、鍵區(qū)350、顯示器355和存儲(chǔ)器360。存儲(chǔ)器360包括基本操作系統(tǒng)(OS)程序361和一個(gè)或多個(gè)應(yīng)用362。

RF收發(fā)機(jī)310a-310n從各自的天線305a-305n接收由網(wǎng)絡(luò)100的AP 102發(fā)送的到來的RF信號(hào)。RF收發(fā)機(jī)310a-310n將到來的RF信號(hào)下變頻以生成中頻(IF)或基帶信號(hào)。IF或基帶信號(hào)被發(fā)送到RX處理電路325，其通過濾波、解碼和/或數(shù)字化該基帶或IF信號(hào)來生成已處理的基帶信號(hào)。RX處理電路325將已處理的基帶信號(hào)發(fā)送到揚(yáng)聲器330(諸如針對(duì)語音數(shù)據(jù))或主處理器340用于進(jìn)一步處理(諸如針對(duì)網(wǎng)絡(luò)瀏覽器數(shù)據(jù))。

TX處理電路315接收來自麥克風(fēng)320接收模擬或數(shù)字的語音數(shù)據(jù)或來自主處理器340的其它的輸出的基帶數(shù)據(jù)(諸如網(wǎng)絡(luò)數(shù)據(jù)(web data)、電子郵件或交互視頻游戲數(shù)據(jù))。TX處理電路315編碼、復(fù)用和/或數(shù)字化外出的基帶數(shù)據(jù)以生成已處理的基帶或IF信號(hào)。RF收發(fā)機(jī)310a-310n接收來自TX處理電路315的外出的已處理的基帶或IF信號(hào)并且將該基帶或IF信號(hào)上變頻為經(jīng)一個(gè)或多個(gè)天線305a-305n發(fā)送的RF信號(hào)。

主處理器340可以包括一個(gè)或多個(gè)處理器或其它處理設(shè)備并且運(yùn)行存儲(chǔ)在存儲(chǔ)器360中的基本OS程序361以便控制STA 300的整體操作。例如，主處理器340可以按照周知的原理、通過RF收發(fā)機(jī)310a-310n、RX處理電路325和TX處理電路315來控制正向信道信號(hào)的接收和反向信道信號(hào)的發(fā)送。在一些實(shí)施例中，主處理器340包括至少一個(gè)微處理器或微控制器。

主處理器340還能夠運(yùn)行駐留在存儲(chǔ)器360中的其它進(jìn)程或程序，諸如針對(duì)Websocket上的媒體流的操作。主處理器340可按運(yùn)行中的進(jìn)程的要求將數(shù)據(jù)移入或移出存儲(chǔ)器360。在一些實(shí)施例中，主處理器340被配置為基于OS程序361或響應(yīng)于從AP 102或運(yùn)營商接收的信號(hào)來運(yùn)行應(yīng)用362。主處理器340還耦接到I/O接口345，其為STA 300提供連接到諸如膝上型計(jì)算機(jī)和掌上型計(jì)算機(jī)的其它設(shè)備的能力。I/O接口345是這些附件和主控制器340之間的通信路徑。

主處理器340還耦接到鍵區(qū)350和顯示器單元355。STA 300的操作者可以使用鍵區(qū)350來鍵入數(shù)據(jù)到STA 300。顯示器355可以是液晶顯示器或能夠渲染諸如來自網(wǎng)站的文本和/或至少有限的圖形的其它顯示器。

存儲(chǔ)器360耦接到主處理器340。處理器360的部分可以包括隨機(jī)存取存儲(chǔ)器(RAM)，并且存儲(chǔ)器360的另一部分可以包括快閃存儲(chǔ)器或其它只讀存儲(chǔ)器(ROM)。

盡管圖2和圖3示出了計(jì)算系統(tǒng)中的設(shè)備的示例，但是可以對(duì)圖2和圖3進(jìn)行各種變化。例如，圖2和圖3中的各種組件可以被組合、進(jìn)一步細(xì)分、或省略，并且附加的組件可以根據(jù)特定的需要而添加。作為特定的示例，主處理器340可以被劃分成多個(gè)處理器，諸如一個(gè)或多個(gè)中央處理單元(CPU)以及一個(gè)或多個(gè)圖形處理單元(GPU)。并且，盡管圖3示出了被配置為移動(dòng)電話或智能電話的客戶端設(shè)備300，但是客戶端設(shè)備可以被配置為作為其它類型的移動(dòng)的或固定的設(shè)備來操作。此外，如同計(jì)算和通信網(wǎng)絡(luò)，客戶端設(shè)備和服務(wù)器也可以以多種配置出現(xiàn)，并且圖2和圖3不將本公開限制為任何特定的客戶端或服務(wù)器。

通過HTTP的動(dòng)態(tài)自適應(yīng)流(Dynamic Adaptive Streaming over HTTP，DASH)近來已被3GPP和MPEG標(biāo)準(zhǔn)化。針對(duì)自適應(yīng)HTTP流的若干其它專有的解決方案，諸如的HTTP直播流(HTTP Live Streaming，HLS)和的平滑流，現(xiàn)今正被商業(yè)性地部署。相比之下，DASH是完全開放并且已標(biāo)準(zhǔn)化的媒體流解決方案，其驅(qū)動(dòng)了不同實(shí)施方式之間的互操作性。

圖4示出了根據(jù)本公開的實(shí)施例的自適應(yīng)的HTTP流架構(gòu)。圖4所示的HTTP流架構(gòu)400的實(shí)施例只是用于闡述。其它實(shí)施例可以在不脫離本公開的范圍的情況下被使用。

在HTTP流架構(gòu)400中，內(nèi)容在內(nèi)容準(zhǔn)備405步驟中被準(zhǔn)備。內(nèi)容由HTTP流服務(wù)器410傳遞。HTTP流服務(wù)器410可以被配置為與服務(wù)器104相同或類似。在流中，內(nèi)容被緩存或緩沖在HTTP緩存415中并且進(jìn)一步被流式傳輸?shù)紿TTP流客戶端420。HTTP流客戶端420可以是客戶端106-114的其中一個(gè)。

在DASH中，內(nèi)容準(zhǔn)備405步驟需要被執(zhí)行，其中內(nèi)容被分成多個(gè)分段。初始化分段被創(chuàng)建以攜帶配置媒體播放器所必要的信息。只有這樣才能消費(fèi)媒體分段。內(nèi)容通常以多個(gè)變體，一般是若干比特率，被編碼。每個(gè)變體對(duì)應(yīng)于該內(nèi)容的再現(xiàn)(Representation)。內(nèi)容再現(xiàn)可以彼此替換或者它們可以彼此補(bǔ)充。在前面的情況中，客戶端只能從替換的再現(xiàn)組中選擇一個(gè)替換。替換的再現(xiàn)被分組到一起作為適應(yīng)集?？蛻舳丝梢岳^續(xù)添加包含附加的媒體組件的補(bǔ)充再現(xiàn)。

提供給DASH流的內(nèi)容需要向客戶端420描述。這是使用媒體呈現(xiàn)描述(Media Presentation Description，MPD)文件來進(jìn)行的。MPD是包含內(nèi)容的描述、內(nèi)容的時(shí)段、適應(yīng)集、內(nèi)容的再現(xiàn)和最重要地如何訪問內(nèi)容的每個(gè)分段的XML文件。MPD元素是MPD文件中的主元素。它包含關(guān)于內(nèi)容的一般信息，諸如它的類型和內(nèi)容可用的時(shí)間窗口。MPD包含一個(gè)或多個(gè)時(shí)段(Period)，每個(gè)時(shí)段描述內(nèi)容的時(shí)間分段。每個(gè)時(shí)段可以包含被分組到一個(gè)或多個(gè)適應(yīng)集的內(nèi)容的一個(gè)或多個(gè)再現(xiàn)。每種再現(xiàn)是一個(gè)或多個(gè)內(nèi)容組件的編碼并且具有特定的配置。再現(xiàn)主要在它們的帶寬要求、它們所包含的媒體組件、所使用的編解碼器、語言等方面不同。

圖5示出了根據(jù)本公開的實(shí)施例的MPD結(jié)構(gòu)。圖5所示的MPD結(jié)構(gòu)500的實(shí)施例只是用于闡述。其它實(shí)施例可以在不脫離本公開范圍的情況下被使用。

在圖5所示的示例中，MPD結(jié)構(gòu)500包括具有許多時(shí)段510的媒體呈現(xiàn)505。每個(gè)時(shí)段510包括許多適應(yīng)集515。每個(gè)適應(yīng)集515包括許多再現(xiàn)520。每個(gè)再現(xiàn)520包括分段信息525。分段信息525包括初始分段530和許多媒體分段535。

在DASH的其中一個(gè)部署場(chǎng)景中，使用基于ISO的文件格式及其派生格式(MP4和3GP文件格式)。內(nèi)容被存儲(chǔ)在所謂的電影片段(fragment)中。每個(gè)電影片段包含媒體數(shù)據(jù)和相對(duì)應(yīng)的元數(shù)據(jù)。媒體數(shù)據(jù)通常是來自所述再現(xiàn)的所有媒體組件的媒體樣本的集合。每個(gè)媒體組件被描述為文件的軌道。

HTTP流

HTTP是基于請(qǐng)求/響應(yīng)的協(xié)議。客戶端設(shè)備300建立到服務(wù)器200的連接以發(fā)送它的HTTP請(qǐng)求。服務(wù)器200接受來自客戶端設(shè)備300的連接以接收HTTP請(qǐng)求并將響應(yīng)發(fā)送回客戶端設(shè)備300。在標(biāo)準(zhǔn)的HTTP模型中，服務(wù)器200不能發(fā)起到客戶端的連接，也不能發(fā)送未請(qǐng)求的HTTP響應(yīng)。為了在HTTP上執(zhí)行媒體流，客戶端設(shè)備300然后不得不一個(gè)分段505接一個(gè)分段505地請(qǐng)求媒體數(shù)據(jù)。這造成了明顯的用于請(qǐng)求的上行(upstream)通信量以及附加的端到端延遲。

為了改善用于網(wǎng)絡(luò)應(yīng)用的環(huán)境，社區(qū)已開發(fā)了若干所謂的HTTP流機(jī)制。這些機(jī)制使網(wǎng)絡(luò)服務(wù)器200不需要等待來自客戶端設(shè)備300的輪詢請(qǐng)求就能發(fā)送數(shù)據(jù)到客戶端300。用于HTTP流的主要方法(通常記作COMET)，要么是通過保持請(qǐng)求暫緩直到數(shù)據(jù)變成可用，要么通過無限期地保持響應(yīng)開啟。在第一種情況下，新的請(qǐng)求仍將需要在已收到響應(yīng)之后被發(fā)送。在HTTP流中，不終止請(qǐng)求并且不關(guān)閉連接。每當(dāng)數(shù)據(jù)變成可用時(shí)，數(shù)據(jù)之后被推送到客戶端設(shè)備300。

HTTP長(zhǎng)輪詢

關(guān)于傳統(tǒng)的請(qǐng)求，客戶端向服務(wù)器200發(fā)送有規(guī)律的請(qǐng)求并且每個(gè)請(qǐng)求試圖拉取任意可用的數(shù)據(jù)。如果沒有可用的數(shù)據(jù)，服務(wù)器200返回空響應(yīng)或錯(cuò)誤消息?？蛻舳嗽O(shè)備300在稍晚的時(shí)間執(zhí)行輪詢。輪詢頻率依賴于應(yīng)用。在DASH中，這由分段可用初始時(shí)間來確定，但是在客戶端和服務(wù)器之間需要時(shí)鐘同步。

在長(zhǎng)輪詢中，服務(wù)器200試圖通過保持請(qǐng)求暫緩直到所請(qǐng)求的資源變成可用來最小化延遲和輪詢頻率。當(dāng)應(yīng)用于DASH時(shí)，直到所請(qǐng)求的DASH分段變成可用才會(huì)發(fā)送響應(yīng)。相比之下，當(dāng)前的默認(rèn)行為是對(duì)于不可用的分段的請(qǐng)求將是“404錯(cuò)誤”的響應(yīng)。

然而，長(zhǎng)輪詢對(duì)于DASH來說可能不是最佳的，因?yàn)榭蛻舳嗽O(shè)備300仍將不得不發(fā)送對(duì)每個(gè)分段的HTTP請(qǐng)求。也有可能是分段URL是不可預(yù)知的，所以客戶端設(shè)備300將不得不首先得到MPD并且解析它以查明當(dāng)前分段的位置，這帶來了附加的延遲。

HTTP流

HTTP流機(jī)制無限期地保持請(qǐng)求開啟。它不終止請(qǐng)求或不關(guān)閉連接，即使在已向客戶端發(fā)送某些數(shù)據(jù)之后。這一機(jī)制顯著地減少延遲，因?yàn)榭蛻舳撕头?wù)器不需要打開和關(guān)閉連接。該過程由進(jìn)行初始請(qǐng)求的客戶端設(shè)備300啟動(dòng)。客戶端設(shè)備300然后等待響應(yīng)。服務(wù)器200推遲響應(yīng)直到數(shù)據(jù)可用。每當(dāng)數(shù)據(jù)可用時(shí)，服務(wù)器會(huì)將數(shù)據(jù)發(fā)送回客戶端設(shè)備300作為部分的響應(yīng)。這是由HTTP/1.1和HTTP/1.0二者支持的能力。在這一情況下，Content-Length(內(nèi)容-長(zhǎng)度)頭部字段不被提供在響應(yīng)中，因?yàn)樗遣豢深A(yù)知的。代替地，響應(yīng)長(zhǎng)度將通過連接的關(guān)閉來確定。關(guān)于這一HTTP流的方法的主要問題是關(guān)于這些連接的中間節(jié)點(diǎn)的行為不能被保證。例如，中間節(jié)點(diǎn)可能不立即轉(zhuǎn)發(fā)部分的響應(yīng)。中間節(jié)點(diǎn)可以決定緩沖該響應(yīng)并且在稍晚的時(shí)間發(fā)送它。

圖6和圖7示出了根據(jù)本公開的HTTP 1.0和HTTP 1.1之間的區(qū)別。盡管流程圖描述了一系列連續(xù)的信號(hào)，除非明確地聲明，否則不應(yīng)該從關(guān)于執(zhí)行的特定順序的序列中得到如下推論，步驟或其部分的執(zhí)行是連續(xù)地而不是同時(shí)地或以重疊的方式，或所描述的步驟的執(zhí)行完全沒有中介或中間步驟的出現(xiàn)。所述示例中描述的過程由例如服務(wù)器中或客戶端設(shè)備中的處理電路來實(shí)現(xiàn)。

HTTP/2和WebSocket

HTTP協(xié)議需要更大的靈活性早已被察覺，但是社區(qū)不情愿對(duì)最普遍并且大量使用的協(xié)議的其中一個(gè)做出改變。圖6所示的示例示出了HTTP 1.0600允許每次連接只有一個(gè)請(qǐng)求，這造成對(duì)于斜向上和向下的TCP連接的明顯的延遲。對(duì)于來自客戶端設(shè)備300的每個(gè)“get(獲取)”請(qǐng)求，服務(wù)器200發(fā)送連續(xù)的響應(yīng)。即，對(duì)于客戶端設(shè)備300作出的第一個(gè)“get”請(qǐng)求605a，服務(wù)器200發(fā)送連續(xù)的響應(yīng)610a。對(duì)于客戶端設(shè)備300作出的第二個(gè)“get”請(qǐng)求605b，服務(wù)器200發(fā)送連續(xù)的響應(yīng)610b。圖7所示的示例示出了HTTP 1.1 700引進(jìn)了持久的連接和請(qǐng)求管線傳輸(request pipelining)。客戶端設(shè)備300作出的多個(gè)“get”請(qǐng)求后面接著服務(wù)器200發(fā)送的多個(gè)相應(yīng)的響應(yīng)。即，第一個(gè)“get”請(qǐng)求705a、第二個(gè)“get”請(qǐng)求705b和第三個(gè)“get”請(qǐng)求705c，是由客戶端設(shè)備300發(fā)送的。作為響應(yīng)，服務(wù)器200發(fā)送相應(yīng)的第一個(gè)響應(yīng)710a、第二個(gè)響應(yīng)710b和第三個(gè)響應(yīng)710c。關(guān)于持久的連接，同一TCP連接可以被用來發(fā)出多個(gè)請(qǐng)求并且接收它們的響應(yīng)。這避免了經(jīng)歷連接的建立和TCP的慢啟動(dòng)階段。請(qǐng)求管線傳輸允許客戶端在接收先前請(qǐng)求的響應(yīng)之前發(fā)送多個(gè)請(qǐng)求。圖6和圖7所示的示例示出了對(duì)于HTTP 1.0和HTTP 1.1的不同的消息交換序列，其示出了在延遲和鏈路利用率方面的潛在增益。

然而，HTTP 1.1 700引進(jìn)管線傳輸和持久的連接也不滿足所有應(yīng)用需要。例如，即使當(dāng)使用管線傳輸時(shí)，來自服務(wù)器200的響應(yīng)的順序必須和客戶端設(shè)備300請(qǐng)求的順序相同并且如果一個(gè)請(qǐng)求阻塞，后面的請(qǐng)求也將阻塞。即，如果第一個(gè)“get”請(qǐng)求705a阻塞，則第二個(gè)“get”請(qǐng)求705b和第三個(gè)“get”請(qǐng)求705c也阻塞。HTTP 1.1 700也不支持將來自服務(wù)器200的內(nèi)容推送到客戶端設(shè)備300。因而客戶端設(shè)備300將只得到客戶端設(shè)備300已實(shí)際請(qǐng)求的資源。對(duì)于經(jīng)常訪問的網(wǎng)站，很可能，在請(qǐng)求了鏈接所有鏈接資源的主HTML文檔之后，鏈接資源的集合將被請(qǐng)求。因此，客戶端設(shè)備300必須在請(qǐng)求鏈接資源之前等待該主文件被接收并被解析，其可造成在渲染網(wǎng)站時(shí)明顯的延遲。

在以下實(shí)施例中，公開了HTTP/2和WebSocket所提供的新特征。本公開的某些實(shí)施例使能通過HTTP/2和WebSocket的DASH。

HTTP 2.0

HTTP 2.0，這里也被稱為“HTTP/2”，是互聯(lián)網(wǎng)工程任務(wù)組(IETF)的工作草案，其試圖解決HTTP 1.1從前的限制，而同時(shí)保持所有功能不被改變。

HTTP/2引進(jìn)了流的概念，其中流是被客戶端設(shè)備300和服務(wù)器200獨(dú)立對(duì)待的。流被用來攜帶請(qǐng)求并且接收關(guān)于該請(qǐng)求的響應(yīng)，在這之后流被關(guān)閉。消息交換是在幀中進(jìn)行的，其中幀可以是頭部(HEADER)類型或數(shù)據(jù)(DATA)類型，這依賴于幀的有效載荷是什么。此外，還定義了一組控制幀。那些幀被用來取消進(jìn)行中的流(RST_STREAM)、指示流對(duì)比其它流的優(yōu)先級(jí)(PRIORITY)、傳送流的設(shè)置(SETTINGS)、指示沒有更多的流可以在當(dāng)前TCP連接上生成(GOAWAY)、執(zhí)行乒/乓操作(PING和PONG)、提供將數(shù)據(jù)從服務(wù)器推送到客戶端的承諾(PUSH_PROMISE)或前一幀的連續(xù)(CONTINUATION)。在某些實(shí)施例中，幀的長(zhǎng)度最多16383字節(jié)。

HTTP/2還試圖經(jīng)頭部壓縮提高線路上的效率。當(dāng)使用時(shí)，頭部壓縮對(duì)頭部字段名編制索引并且使用數(shù)值標(biāo)識(shí)符來指示哪個(gè)頭部字段被使用。大多數(shù)頭部字段被分配了靜態(tài)的id值，但是頭部壓縮允許動(dòng)態(tài)地將值分配給其它頭部字段。

WebSocket

類似于HTTP/2，在某些實(shí)施例中，WebSocket也被實(shí)現(xiàn)為完全符合HTTP協(xié)議的升級(jí)，其開始于握手過程，在此期間兩端商定將連接升級(jí)到WebSocket。在成功地將連接升級(jí)為WebSocket連接后，數(shù)據(jù)可以同時(shí)在兩個(gè)方向上流動(dòng)，其結(jié)果是全雙工的連接。服務(wù)器200可以在不需要客戶端請(qǐng)求的情況下決定將數(shù)據(jù)發(fā)送到客戶端設(shè)備300。客戶端設(shè)備300也可以發(fā)送多個(gè)請(qǐng)求而不需要等待服務(wù)器響應(yīng)。

實(shí)際上，HTTP/2從WebSocket借用許多概念，諸如握手過程和成幀過程，包括若干幀類型(諸如數(shù)據(jù)、連續(xù)、乒和乓)。WebSocket不定義關(guān)于應(yīng)用數(shù)據(jù)的格式的任何進(jìn)一步的細(xì)節(jié)，并且將其留給應(yīng)用來定義。在握手階段協(xié)商實(shí)際的格式，其中兩端點(diǎn)通過交換Sec-WebSocket-Protocol頭部字段來商定將要使用的子協(xié)議。

根據(jù)本公開的某些實(shí)施例：

客戶端設(shè)備300避免連續(xù)地拉取數(shù)據(jù)；

客戶端設(shè)備300避免同步問題和資源取回錯(cuò)誤；

客戶端設(shè)備300仍然在會(huì)話的控制之下；以及

服務(wù)器200獲得對(duì)會(huì)話的某些控制。

結(jié)果是，本公開的某些實(shí)施例減少體驗(yàn)延遲(experience delay)和網(wǎng)絡(luò)通信量。

在某些實(shí)施例中，定義了成幀協(xié)議來使能在HTTP流上基于推送的自適應(yīng)HTTP流解決方案。成幀協(xié)議使客戶端設(shè)備300能將命令發(fā)送到服務(wù)器200以在流會(huì)話期間執(zhí)行速率自適應(yīng)操作。

圖8示出了根據(jù)本公開的實(shí)施例的支持WebSocket的網(wǎng)絡(luò)。圖8所示的支持WebSocket的網(wǎng)絡(luò)800的實(shí)施例只是用于闡述。其它實(shí)施例可在不脫離本公開的范圍的情況下被使用。

支持WebSocket的網(wǎng)絡(luò)800包括原始服務(wù)器805、一個(gè)或多個(gè)內(nèi)容分發(fā)網(wǎng)絡(luò)(content delivery network，CDN)代理服務(wù)器810和許多客戶端設(shè)備815。原始服務(wù)器805可以被配置為與服務(wù)器200相同或類似。一個(gè)或多個(gè)CDN代理服務(wù)器810可以被配置為與服務(wù)器200相同或類似。一個(gè)或多個(gè)客戶端設(shè)備815可以被配置為與客戶端設(shè)備300相同或類似。CDN代理服務(wù)器810經(jīng)互聯(lián)網(wǎng)820與原始服務(wù)器805通信。互聯(lián)網(wǎng)820可以與網(wǎng)絡(luò)102相同或類似。客戶端設(shè)備815a與CDN代理服務(wù)器810a建立通信連接，通過該連接客戶端設(shè)備815a可以接收來自原始服務(wù)器805的內(nèi)容。客戶端設(shè)備815b與CDN代理服務(wù)器810b建立通信連接，通過該連接客戶端設(shè)備815b可以接收來自原始服務(wù)器805的內(nèi)容?？蛻舳嗽O(shè)備815c與CDN代理服務(wù)器810b建立通信連接，通過該連接客戶端設(shè)備815c可以接收來自原始服務(wù)器805的內(nèi)容。在圖8所示的示例中，WebSocket在最后一跳中被使用以使內(nèi)容從CDN流向客戶端。即，客戶端設(shè)備815b或客戶端設(shè)備815c，或它們兩者，經(jīng)從CDN代理服務(wù)器815b到原始服務(wù)器805的各自的連接通過WebSocket 825來建立自適應(yīng)的HTTP流。

在某些實(shí)施例中，客戶端設(shè)備815b首先檢測(cè)原始服務(wù)器805或CND代理服務(wù)器810b是否支持通過WebSocket的媒體流。盡管實(shí)施例的示出是關(guān)于客戶端設(shè)備815b或額外地包括客戶端設(shè)備815b，但是與流式傳輸?shù)娇蛻舳嗽O(shè)備815c或客戶端設(shè)備815a相對(duì)應(yīng)的實(shí)施例可以在不脫離本公開范圍的情況下被使用。當(dāng)?shù)谝辉O(shè)備確定要么是原始服務(wù)器805、要么是CDN代理服務(wù)器810b時(shí)，客戶端設(shè)備815b經(jīng)CDN代理服務(wù)器810b建立到原始服務(wù)器805的WebSocket連接并且提交指示流中所選擇的再現(xiàn)和位置的初始請(qǐng)求?？蛻舳嗽O(shè)備815b然后按照原始服務(wù)器805推送媒體分段的順序來接收媒體分段。這一過程繼續(xù)直到客戶端設(shè)備815b：

決定選擇或切換為替換的再現(xiàn)；

決定執(zhí)行特技模式操作；

接收要求客戶端動(dòng)作的清單文件更新或其指示；

接收流的結(jié)尾或服務(wù)指示的結(jié)尾；以及

接收來自服務(wù)器的請(qǐng)求以發(fā)送針對(duì)下一分段的請(qǐng)求。

基于客戶端設(shè)備815b的決定或接收，客戶端設(shè)備815b決定創(chuàng)建并且提交給原始服務(wù)器805什么命令。

圖9示出了根據(jù)本公開的實(shí)施例、對(duì)客戶端設(shè)備利用WebSocket的自適應(yīng)的HTTP流過程900。盡管流程圖描述了一系列連續(xù)的步驟，除非明確地聲明，否則不應(yīng)該從關(guān)于執(zhí)行的特定順序的序列中得到如下推論，步驟或其部分的執(zhí)行是連續(xù)地而不是同時(shí)地或以重疊的方式，或所描述的步驟的執(zhí)行完全沒有中介或中間步驟的出現(xiàn)。所述示例中描述的過程由例如客戶端設(shè)備中的處理電路來實(shí)現(xiàn)。

在塊905中，客戶端設(shè)備300接收服務(wù)器200支持WebSocket的指示。服務(wù)器200向客戶端設(shè)備300指示服務(wù)器200樂于升級(jí)到WebSocket以服務(wù)到客戶端設(shè)備300的媒體流會(huì)話。在建立到客戶端設(shè)備300的連接之后，在塊910中，服務(wù)器200接收對(duì)于分段的初始請(qǐng)求?？蛻舳嗽O(shè)備300向服務(wù)器200發(fā)送命令或請(qǐng)求以選擇再現(xiàn)和位置。服務(wù)器200將分段分裝在幀中并且發(fā)送它。在塊915中，客戶端設(shè)備300接收來自服務(wù)器200的分段。服務(wù)器200連續(xù)地發(fā)送后面的分段，諸如通過將分段號(hào)增加1，直到客戶端設(shè)備300接收到新的命令或要求決定。即，在塊920中，要么命令被發(fā)送、要么動(dòng)作被指示為要求，諸如當(dāng)MPD文件更新變成可用時(shí)。塊920中如果沒有要求動(dòng)作，則客戶端設(shè)備300繼續(xù)接收分段，諸如通過返回塊915。塊910中如果要求動(dòng)作，則塊925中客戶端設(shè)備300確定是否終止會(huì)話。塊925中當(dāng)客戶端設(shè)備300決定不終止會(huì)話時(shí)，在塊910中客戶端設(shè)備300向服務(wù)器發(fā)送其它命令以選擇再現(xiàn)和位置。替換地，塊925中當(dāng)客戶端設(shè)備300決定終止會(huì)話時(shí)，塊930中，客戶端設(shè)備300要么終止該會(huì)話、要么切換到另一服務(wù)器。

圖10示出了根據(jù)本公開的實(shí)施例、對(duì)服務(wù)器利用WebSocket的自適應(yīng)的HTTP流過程1000。盡管流程圖描述了一系列連續(xù)的步驟，除非明確地聲明，否則不應(yīng)該從關(guān)于執(zhí)行的特定順序的序列中得到如下推論，步驟或其部分的執(zhí)行是連續(xù)地而不是同時(shí)地或以重疊的方式，或所描述的步驟的執(zhí)行完全沒有中介或中間步驟的出現(xiàn)。所述示例中描述的過程由例如服務(wù)器中的處理電路來實(shí)現(xiàn)。

塊1005中，服務(wù)器200向客戶端設(shè)備300指示服務(wù)器200樂于升級(jí)到WebSocket以服務(wù)到客戶端設(shè)備300的媒體流會(huì)話。在客戶端設(shè)備300接收到接收服務(wù)器200支持WebSocket的指示后，在塊1010中服務(wù)器200與客戶端設(shè)備300建立傳入的WebSocket連接。在建立到客戶端設(shè)備300的連接后，塊1015中服務(wù)器200接收初始命令或?qū)τ诜侄蔚恼?qǐng)求。即，響應(yīng)于客戶端設(shè)備300向服務(wù)器200發(fā)送命令或請(qǐng)求以選擇再現(xiàn)和位置，服務(wù)器200通過將分段封裝在幀中并且將分段發(fā)送到客戶端設(shè)備300來處理流命令。塊1020中，服務(wù)器200向客戶端設(shè)備300發(fā)送下一分段。服務(wù)器200連續(xù)地發(fā)送后面的分段，諸如通過將分段號(hào)增加1，直到客戶端設(shè)備300接收到新的命令或要求決定。即，在塊1025中，服務(wù)器200確定是否要求客戶端動(dòng)作，諸如當(dāng)MPD文件更新變成可用時(shí)。如果塊1025中沒有要求動(dòng)作，則服務(wù)器200繼續(xù)發(fā)送分段，諸如通過返回塊1020。如果塊1025中要求客戶端設(shè)備動(dòng)作，則塊1030中服務(wù)器200向客戶端設(shè)備300發(fā)送指示相應(yīng)動(dòng)作的命令，諸如當(dāng)MPD文件更新變成可用時(shí)。

在某些實(shí)施例中，通過WebSocket的自適應(yīng)的HTTP流被實(shí)現(xiàn)為WebSocket協(xié)議的子協(xié)議。命令被定義為WebSocket幀頭部的擴(kuò)展數(shù)據(jù)。以下是從客戶端設(shè)備300到服務(wù)器200的可能的命令：

向特定再現(xiàn)請(qǐng)求數(shù)據(jù)流，可以從初始(init)分段和特定分段號(hào)開始。請(qǐng)求可以是第一分段的統(tǒng)一資源定位符(URL)或者請(qǐng)求可以是呈現(xiàn)(Presentation)標(biāo)識(shí)符、再現(xiàn)(Representation)標(biāo)識(shí)符和開始分段號(hào)；以及

向服務(wù)器請(qǐng)求停止流。

以下是從服務(wù)器200到客戶端設(shè)備300的可能的命令：

關(guān)于MPD更新的信息；

被發(fā)送到客戶端的分段的標(biāo)識(shí)符；每一分段單獨(dú)地成幀并且前面是它的URL或其它標(biāo)識(shí)；

請(qǐng)求客戶端選擇，諸如由于新的時(shí)段。這個(gè)命令包括時(shí)間軸上的當(dāng)前位置以及為什么請(qǐng)求客戶端選擇的其它信息；以及

關(guān)于過早地結(jié)束會(huì)話或終止流會(huì)話的信息。

分段和MPD更新被成幀以使客戶端設(shè)備能分別識(shí)別每個(gè)分段。分段可以被片段化以便每個(gè)電影片段可以被作為唯一片段發(fā)送。

通過HTTP/2和WebSocket的DASH

為了利用新的協(xié)議HTTP/2和WebSocket的全部的潛能，DASH應(yīng)用必須定義將在已升級(jí)的連接之上使用的新的子協(xié)議。當(dāng)HTTP/2比WebSocket定義更多功能時(shí)，因?yàn)樵谀欠N情況下的子協(xié)議意味著等價(jià)于HTTP 1.1的功能，所以在HTTP/2的情況下需要執(zhí)行的工作將更少。

本公開的某些實(shí)施例示出了對(duì)DASH應(yīng)用可用的功能：

DASH客戶端設(shè)備能最小化向服務(wù)器的請(qǐng)求數(shù)；

DASH客戶端設(shè)備能進(jìn)行迅速的速率自適應(yīng)；

DASH客戶端設(shè)備能最小化延遲，諸如在直播流的情況中，其中內(nèi)容被即時(shí)生成；以及

DASH/Web服務(wù)器能基于不同再現(xiàn)中的數(shù)據(jù)對(duì)回放的重要性來對(duì)這些數(shù)據(jù)劃分優(yōu)先次序。

基于這些目標(biāo)，定義了對(duì)于HTTP/2和WebSocket的新的子協(xié)議。

對(duì)于WebSocket的DASH子協(xié)議

子協(xié)議由名字“dash”來標(biāo)識(shí)。想要使用WebSocket用于DASH流的客戶端設(shè)備包括關(guān)鍵詞“dash”作為Sec-WebSocket-Protocol頭部字段的部分，以及協(xié)議升級(jí)請(qǐng)求。

在成功地將協(xié)議升級(jí)為WebSocket之后，客戶端和服務(wù)器交換DASH數(shù)據(jù)幀(操作碼‘文本’或‘二進(jìn)制’或其任意‘連續(xù)’幀)。DASH幀格式定義為如下：

STREAM_ID：8比特是當(dāng)前流的標(biāo)識(shí)符，其允許在同一websocket連接上復(fù)用多個(gè)請(qǐng)求/響應(yīng)。

CMD_CODE：8比特指示按照這個(gè)請(qǐng)求/響應(yīng)發(fā)送的DASH命令。當(dāng)前定義的命令如下：

F：3比特--這一字段提供將要基于所述命令而被設(shè)置并且被解釋的一組標(biāo)志。

EXT_LENGTH：13比特--提供先于應(yīng)用數(shù)據(jù)的擴(kuò)展數(shù)據(jù)的字節(jié)的長(zhǎng)度。

對(duì)于HTTP/2的DASH子協(xié)議

如早前討論的，HTTP/2可以被認(rèn)為是WebSocket的超集，HTTP/2提供等價(jià)于HTTP 1.1協(xié)議的子協(xié)議。為WebSocket DASH子協(xié)議所提出的若干功能已由HTTP/2協(xié)議來提供，諸如支持對(duì)于多個(gè)流，取消特定流上的當(dāng)前傳輸并且使用PUSH_PROMISE幀來將數(shù)據(jù)推送到客戶端。

為了保持與HTTP/2的向后兼容，DASH子協(xié)議使用HEADERS幀來傳達(dá)DASH特定的信息和命令。出于這一目的，定義了新的頭部字段，其攜帶用逗號(hào)分開的名字的集合＝值的對(duì)。DASH頭部字段被稱為“Dash”。介紹以下命令：

(a)協(xié)商對(duì)DASH子協(xié)議的支持；

(b)請(qǐng)求特定再現(xiàn)的連續(xù)流；

(c)請(qǐng)求客戶端決定；以及

(d)傳送MPD更新

盡管已用示例實(shí)施例描述了本公開，但各種變化和修改可以被建議給本領(lǐng)域技術(shù)人員。意圖本公開包含落入所附權(quán)利要求范圍內(nèi)的變化和修改。