本發(fā)明涉及多播流傳輸(multicast streaming)領域，并且具體地涉及用于與單播流同步的包括多個塊的多播流的生成。

背景技術：

當前通過IP網(wǎng)絡傳送的直播電視使用兩種完全不同的網(wǎng)絡技術中的一個：一個是基于多播的網(wǎng)絡技術，并且另一個是基于單播的網(wǎng)絡技術。采用多播傳輸，攜帶內(nèi)容的單個多播流被從內(nèi)容服務器同時推送到多個網(wǎng)絡節(jié)點，這些網(wǎng)絡節(jié)點復制所述內(nèi)容，并且根據(jù)需要轉(zhuǎn)發(fā)到任意后續(xù)節(jié)點或者客戶端。采用單播傳輸，通常使用通過TCP的HTTP以及自適應比特率技術將多個內(nèi)容流從該服務器拉出(pull)，一個內(nèi)容流用于每一個消耗內(nèi)容的裝置。

當在相同的時間將相同的內(nèi)容傳送給多個終端裝置時，多播對網(wǎng)絡進行了有效的使用，但是通常需要連續(xù)分配網(wǎng)絡資源而不考慮觀看量。此外，諸如一些平板電腦以及智能電話這樣的很多終端裝置當前不支持多播。

單播面臨通過網(wǎng)絡發(fā)送相同內(nèi)容的多個副本，但是不需要網(wǎng)絡資源的獨立使用分配。此外，單播能夠傳送給所有終端裝置，即使在存在到該終端裝置的低的或者變化的網(wǎng)絡吞吐量的情況下，這對于通過例如無線技術連接的裝置是頻繁發(fā)生的。

US專利申請2013/0024582描述了這樣一種系統(tǒng)和方法，其用于響應于并發(fā)訪問媒體內(nèi)容的需求的變化而在媒體內(nèi)容的單播傳送和多播傳送之間動態(tài)地切換。此外，包括在視頻幀中的序列號被用于在單播流內(nèi)容和多播流內(nèi)容之間對齊(align)。

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

本發(fā)明的實施方式的目的是，提供一種生成用于攜帶視頻內(nèi)容的多播流的、支持改進的切換到單播流的和從單播流切換的方法。

根據(jù)本發(fā)明的一個方面，提供了一種多播視頻傳送的方法，所述方法包括如下步驟：

接收編碼的視頻內(nèi)容的多個片段，其中，每個片段包括編碼的視頻的多個幀；

生成多個傳輸協(xié)議包，其中，每個片段被攜帶在一個或者多個傳輸協(xié)議包的有效載荷中；

使用第一片段標識符來標記每個傳輸協(xié)議包，其中，第一片段標識符標識攜帶給定片段的一個或者多個傳輸協(xié)議包；

傳輸包括多個傳輸協(xié)議包的多播流。

第一片段標識符可以是與片段相關聯(lián)的序列號，其中，對于不同的片段，序列號的值是不同的，并且使用與給定片段相關聯(lián)的序列號來標記攜帶該片段的每個傳輸協(xié)議包。

該方法還可包括如下步驟：使用第二片段標識符來標記每個傳輸協(xié)議包，其中，該第二標識符是如下的偏移，該偏移包括如下數(shù)值，該數(shù)值隨著攜帶給定片段的每個傳輸協(xié)議包而遞增，并且對于新的片段的第一個包被重置。用于標記給定包的偏移可表示在針對給定片段的先前包中攜帶的數(shù)據(jù)的字節(jié)的總數(shù)。

片段標識符可以是傳輸協(xié)議有效載荷頭部字段。傳輸協(xié)議可以是實時傳輸協(xié)議。

多播流可包括：使用用戶數(shù)據(jù)報協(xié)議封裝在IP包中的傳輸協(xié)議包。

可以以傳輸流塊的形式來攜帶所述片段中的每一個，并且其中，每個傳輸流塊包括多個傳輸流包。

本發(fā)明的示例允許多播和單播一起使用，相較于單獨使用任一技術更加順暢和有效地傳送直播電視內(nèi)容。通過標記塊邊界，改進了在多播和單播之間的切換，其在傳輸層級處完成，并且因此避免了需要檢查視頻內(nèi)容本身以及需要在圖片級的幀或者組來同步。

在另選的示例中，代理被引入到內(nèi)容服務器和客戶端之間的路徑中，并且允許通過單播或者多播將內(nèi)容傳送到該代理。代理可位于路由器或者集線器中。根據(jù)各種因素來做出是否能夠使用多播和單播的選擇，例如網(wǎng)絡條件、以及根據(jù)在觀看該內(nèi)容的客戶端的總數(shù)量方面該內(nèi)容被觀看的受歡迎程度。代理與內(nèi)容服務器通信從而確定該客戶端請求的內(nèi)容通過單播和/或多播是否是可用的。代理基于其對諸如到該客戶端的網(wǎng)絡吞吐量的因素的了解，來確定哪一種是最適合的使用形式，并且在選擇多播傳送的情況下，執(zhí)行必要的功能，例如IGMP加入，從而接收多播流，緩沖多播流，并且隨后能夠多播流其作為單播資源呈現(xiàn)給客戶端。通過這樣做，可以針對受歡迎的內(nèi)容使用多播傳送到代理，其中，單播會低效率地使用網(wǎng)絡容量，但是如果這些客戶端不支持多播，還允許從代理到客戶端通過單播的后續(xù)傳送。

附圖說明

為了更好地理解本發(fā)明，現(xiàn)在將僅通過舉例的方式來參考附圖，其中：

圖1是本發(fā)明的示例中的網(wǎng)絡圖；

圖2是更為詳細地示出了內(nèi)容生成器和內(nèi)容服務器的系統(tǒng)圖；

圖3是概括了本發(fā)明的示例的主要步驟的流程圖；

圖4例示了如何使用RTP經(jīng)由IP包來攜帶傳輸流塊；

圖5示出了UDP頭部的格式；

圖6示出了RTP頭部的格式；

圖7示出了在本發(fā)明的示例中的RTP有效載荷頭部格式的格式；

圖8示出了在本發(fā)明的示例中的完整IP包的格式。

具體實施方式

在此參考具體的示例來描述本發(fā)明。但是，本發(fā)明不限制于這些示例。

本發(fā)明的示例提出了一種生成用于傳輸諸如直播電視這樣的視頻內(nèi)容的多播流的方法。首先，視頻內(nèi)容被編碼，并且被分段(segmented)成時間塊。每個塊隨后取決于該塊的大小而被封裝在一個或者多個RTP包中，并且采用塊標簽來標記每個RTP包，以指示在塊之間的邊界位于這些包中的哪一個。隨后通過封裝該RTP包來生成多播流，優(yōu)選地使用UDP來封裝在IP包中。通過在該RTP有效載荷頭部中的專用字段來提供該塊標簽。該塊標簽可以是塊索引或者塊偏移。兩者可以被獨立地和組合地用于確定塊之間的邊界。

圖1示出了包括與內(nèi)容服務器104通信的內(nèi)容生成器102的系統(tǒng)100。內(nèi)容生成器負責接收諸如直播TV這樣的未壓縮的視頻內(nèi)容，并且編碼和封裝該視頻內(nèi)容，以傳輸?shù)絻?nèi)容服務器104。內(nèi)容服務器104負責存儲接收到的視頻內(nèi)容，并且在單播傳送的情況下，內(nèi)容被從該服務器拉出，而對于多播傳送，內(nèi)容被從該服務器中推送到通過該網(wǎng)絡106連接的合適配置的客戶端。在該示例中，示出了三個客戶端108、110和112?？蛻舳丝梢允沁m于支持例如MPEG DASH或者蘋果公司的HTTP直播流媒體(HLS)的標準HTTP自適應比特率流傳輸客戶端?？蛻舳诉m于發(fā)現(xiàn)內(nèi)容、請求和處理清單文件、通過單播請求內(nèi)容的塊、以及處理那些塊用于觀看。同時，可以通過網(wǎng)絡106直接將內(nèi)容傳送到這些客戶端，可以通過位于每個客戶端的代理實現(xiàn)傳送，這具有某些好處。

內(nèi)容服務器104還包括如下機構(gòu)：其用于在諸如電視節(jié)目或者電影這樣的任意給定編碼內(nèi)容傳送期間，在單播傳送方法和多播傳送方法之間切換，并生成多播流。

在圖2中更詳細地示出了內(nèi)容生成器102以及內(nèi)容服務器104。將會參考圖3的流程圖來描述內(nèi)容生成器102和內(nèi)容服務器104的操作和部件，圖3的流程圖大體描繪了總體方法。

如在圖2中所示，內(nèi)容生成器102包括：視頻編碼器206、音頻編碼器208、分段模塊210、封裝模塊212、以及輸出接口214。通過該內(nèi)容生成器102來接收包括未壓縮的視頻流202和未壓縮的音頻流的未壓縮的視頻內(nèi)容。具體地，視頻編碼器206獲得未壓縮的視頻流202，并且編碼該視頻從而生成編碼的視頻流。在該示例中，所使用的視頻編碼方法是根據(jù)ITU H.264標準的，但是本發(fā)明不限制于這一標準，并且可以替代使用其他的編碼方法。類似地，音頻編碼器208獲得未壓縮的音頻流204，并且編碼該音頻從而生成編碼的音頻流。在該示例中，該音頻編碼方法是MPEG-4HEAAC v2，但是本發(fā)明不限制于這一標準，并且可以替代使用其他的編碼方法。該未壓縮的視頻流可以被以多個比特率來編碼(相關聯(lián)的未壓縮音頻流通常僅被以一個比特率來編碼，但是也可以被以多個比特率來編碼)，因此生成針對每個比特率的編碼的流。該編碼的視頻流包括多個幀或者圖片，它們進而能夠被聚合成圖片的組或者GOP。圖3的步驟300中示出了對視頻內(nèi)容進行編碼的該第一步。

接下來在步驟302中，通過分段模塊210將編碼的視頻流和編碼的音頻流(或者如果以多個比特率來編碼內(nèi)容，則每個編碼的視頻流和編碼的音頻流)分段為離散視頻和音頻片段或者塊?？梢韵胂蟮氖?，每個塊等同于在未壓縮的視頻/音頻的時長中的2秒到15秒之間，但是可以使用更長或者更短的時長(duration)。同時分段模塊210被示出為在編碼器206和208之后操作，可以在對未壓縮的視頻和音頻流進行編碼之前對它們執(zhí)行該分段。因此，未壓縮的視頻和音頻可以首先被分段，并且隨后所獲得的未壓縮的片段可以被編碼，以生成編碼的視頻和音頻片段。

分段模塊210可以考慮服務要求來選擇片段時長。例如較短的片段允許在流之間(同時在單播流和多播流之間，或者在不同的編碼比特率之間)的切換發(fā)生得更快。但是，較長的片段更容易通過系統(tǒng)部件來處理，具體地通過CDN(內(nèi)容傳送網(wǎng)絡)節(jié)點來處理，但是會引起在傳送模式之間的較慢的切換，并且可給直播服務引入更多的端到端延時。

在步驟304中，通過封裝模塊212處理視頻和音頻片段。在該示例中，封裝模塊212的輸出是所謂的復用格式，例如在IS 13818-1中規(guī)定的MPEG-2傳輸流。該MPEG-2傳輸流通常用于實時的數(shù)字電視傳送。封裝模塊還可以以所謂的非復用格式來輸出，例如在IS 14496-12中規(guī)定的ISO基本媒體文件格式。MP4片段也可以被替代輸出。

MPEG-2傳輸流包括多個傳輸流包。每個傳輸流包攜帶184字節(jié)的有效載荷數(shù)據(jù)，由4字節(jié)頭部作為前綴。編碼的視頻和音頻片段被攜帶在該傳輸流有效載荷中，其中，每個有效載荷通常攜帶單種媒體類型，例如，音頻、視頻或者字幕數(shù)據(jù)。通常，會需要數(shù)個傳輸流包以攜帶音頻和視頻的每一個片段。所需要的傳輸流包的精確數(shù)量將依賴于通過分段模塊210創(chuàng)建的音頻和視頻的每個片段的時長。因此，封裝模塊112將輸出多個傳輸流塊，以攜帶各個視頻和音頻片段，并且每個傳輸流塊包括一個或者多個傳輸流包。如果使用MP4片段，則數(shù)個MP4片段將被用于攜帶相同的片段。

本領域技術人員將會意識到，通過編碼器、分段模塊以及封裝模塊執(zhí)行的功能可以通過單個、合適配置的、通用視頻編碼器模塊來執(zhí)行。

在步驟306中，傳輸流塊被傳輸給輸出接口214，在該輸出接口214處它們進而被傳送到內(nèi)容服務器120。

此外，內(nèi)容生成器102還生成清單文件，并且還將該清單文件傳輸?shù)絻?nèi)容服務器104，所述清單文件描述了編碼的內(nèi)容(在該示例中是傳輸流塊)，以及如何能夠獲得它。在MPEG-DASH下，該清單被稱為MPD(Media Presentation Description，媒體呈現(xiàn)描述)。蘋果公司的自適應視頻流傳輸技術，即HLS(HTTP直播流媒體)，提供了播放列表文件(.m3u文件)形式的清單。

如后面將要描述的，在本發(fā)明的一個示例中，清單文件可以被內(nèi)容服務器修改，從而發(fā)出從單播到多播的切換的信號。該清單文件描述了針對每個傳輸流塊的可用比特率，以及每個傳輸流塊所位于的位置(該塊被存儲在內(nèi)容服務器104中的位置的地址)。該清單文件被客戶端用于單播流傳輸。

內(nèi)容服務器120在輸入接口222處從內(nèi)容生成器102接收呈傳輸流塊形式的塊中的編碼的內(nèi)容以及任意相關聯(lián)的清單文件。內(nèi)容服務器104包括：輸入接口222、用于存儲視頻內(nèi)容的數(shù)據(jù)存儲器224、多播流生成器230、切換邏輯232、以及輸出接口234。數(shù)據(jù)存儲器224可以形成標準網(wǎng)絡服務器的一部分，該標準網(wǎng)絡服務器能夠經(jīng)由輸出接口234響應于單播請求而服務于各個傳輸流塊。通過單播提供的內(nèi)容在客戶端請求時從網(wǎng)絡服務器中被有效地“拉出”。

傳輸流塊和清單文件被從輸入接口222傳輸?shù)綌?shù)據(jù)存儲器224，它們被存儲在該數(shù)據(jù)存儲器224中。數(shù)據(jù)存儲器224可以存儲多個清單文件228(所述多個清單文件228中的一個用于視頻的每個目的地項)以及視頻內(nèi)容226(呈傳輸流塊的形式)。如之前建議的，可以有多個相同的視頻內(nèi)容的版本，每個以不同比特率來編碼，這些反映在相關聯(lián)的清單文件中。

多播流生成器230負責生成多播流，所述多播流通常將攜帶多個傳輸流塊。多播流被“推”出至客戶端。

客戶端可以通過首先向該內(nèi)容服務器104發(fā)出對與期望的內(nèi)容相關聯(lián)的合適的清單文件的請求來發(fā)起單播流傳輸。在接收到清單文件后，客戶端可以使用與在清單中發(fā)現(xiàn)的每個塊相關聯(lián)的位置信息來發(fā)出對編碼塊、傳輸流塊的具體請求。該請求針對每個塊采用HTTP請求的形式，并且該請求被內(nèi)容服務器104處理，并且具體地被網(wǎng)絡服務器部件處理。傳輸流塊被網(wǎng)絡服務器封裝為標準TCP/IP包，并且通過網(wǎng)絡傳送到客戶端。傳送機構(gòu)因此是一個可靠的傳送機構(gòu)?？蛻舳巳鐝膬?nèi)容服務器104中請求的，還可以請求更新的清單文件。后面將會更詳細描述該過程。

內(nèi)容服務器104中的切換邏輯232確定是否使得傳輸流塊可用于通過多播的傳送以及通過單播的傳送，并且當需要的時候，將指示多播流生成器230生成多播流，并且發(fā)出該多播流是可用的信號?？梢酝ㄟ^如下面將要描述的對該清單文件的合適的更新來執(zhí)行后者。

切換邏輯232針對每個編碼的內(nèi)容流，確定這些編碼的塊的哪個(如果有的話)通過多播傳送和通過單播傳送是可用的。例如，切換邏輯232可以在一個時間點上確定對于給定段內(nèi)容的所有內(nèi)容塊僅通過單播是可用的；并且在稍后的時間點上，切換邏輯232可以確定該內(nèi)容(或者以一個特定比特率編碼的具體流)還應附加地通過多播是可用的；并且在甚至更后的時間點上，切換邏輯232可以確定所有的內(nèi)容塊再次僅可以通過單播是可用的。

關于何時從單播切換到多播的決定可基于請求特定段內(nèi)容的客戶端的數(shù)量。如果網(wǎng)絡僅允許單個多播流，則最受歡迎的內(nèi)容可以被選擇用于多播傳送，從而降低網(wǎng)絡中使用的總帶寬。但是，其可能沒有那么簡單，因為內(nèi)容可以被以不同比特率編碼，并且客戶端可處理的速率也可以變化，因此切換決定會更加復雜。但是，因此對于切換邏輯232來說，在任何時候知道有多少客戶端正在經(jīng)由單播接收哪個內(nèi)容，以及經(jīng)由多播接收哪個內(nèi)容以能夠做出合適的切換決定是非常重要的。

當切換邏輯確定所存儲的內(nèi)容中的一些經(jīng)由多播傳送應當是可用的時，內(nèi)容服務器104修改清單文件，從而也表示多播傳送的可能性以及如何接收該多播流。內(nèi)容服務器隨后在切換邏輯已經(jīng)表示用于多播傳送的多播流中傳輸該編碼的內(nèi)容。

在已知的系統(tǒng)中，視頻的多播流傳輸通過在使用諸如通過IP的RTP這樣的傳送機構(gòu)之前，編碼該內(nèi)容并且將所編碼的內(nèi)容封裝到傳輸流包中來工作。但是，這一方法并沒有導致其自身向攜帶視頻的單播切換以及從攜帶視頻的單播切換，其中，需要在所編碼的內(nèi)容之間的精確同步，以避免干擾內(nèi)容的播放(playback)。

在本發(fā)明的示例中，如上所述，內(nèi)容已經(jīng)被劃分為預定時長的片段，并且被攜帶在傳輸流塊中。隨后，使用諸如RTP(實時傳輸協(xié)議)這樣的傳輸協(xié)議來封裝傳輸流塊。具體地，傳輸流塊被攜帶在該包中，具體地在RTP有效載荷中，并且使用UDP(用戶數(shù)據(jù)報協(xié)議)將該RTP包封裝在IP包中，用于多播傳輸。

圖4例示出了傳輸流塊和RTP包的格式，其中它們被攜帶用于多播流。示出了三個傳輸流塊400、402和404，每個傳輸流塊攜帶如之前所述的所分段的內(nèi)容。每個傳輸流塊包括多個傳輸流包410，其中，每個傳輸流包具有相關聯(lián)的頭部412和有效載荷414。傳輸流包被攜帶在RTP包的有效載荷420中。每個新的傳輸流塊在新的RTP有效載荷中開始，因此避免了一個RTP有效載荷可以攜帶一個傳輸流塊的結(jié)束(end)以及下一個傳輸流塊的開始(start)的情況。RTP包包括標準RTP頭部422。使用UDP將包括RTP頭部422和RTP有效載荷420的RTP包封裝到IP包430中，并且因此示出了UDP頭部422和IP頭部426。實際上，該RTP有效載荷420和RTP頭部422形成了該UDP包的有效載荷，并且該UDP有效載荷和該UDP頭部424進而形成該IP包430的有效載荷。

舉例來說，如果內(nèi)容是1Mbit/s視頻流，并且被分段為2秒的塊，每個塊將包含2Mbit或者250Kbyte。因此，每個塊將通過大約190個RTP有效載荷來攜帶，每個RTP有效載荷包括最多七個188字節(jié)的傳輸流包。

圖5中更詳細地示出了UDP頭部424的格式。

圖6中更詳細地示出了RTP頭部422的格式。

在本發(fā)明的示例中，提出了使用附加的RTP頭部來幫助在多播流中識別塊邊界。這需要通過接收客戶端來識別單獨的塊，從而使得干脆利索地進行在通過單播傳送的塊和那些通過多播傳送的塊之間的切換。在本發(fā)明的示例中，提出了使用一些附加標簽來表示哪些RTP有效載荷正攜帶哪些塊，以及塊邊界位于哪里。在實踐中，每個傳輸流塊將通過很多RTP有效載荷來攜帶，并且因此塊邊界在很多RTP有效載荷之后出現(xiàn)(參見上面其中2秒的塊需要大約190個RTP有效載荷的示例)。在一個最簡單的方案中，攜帶塊的結(jié)束(end)的RTP包可以被標記，以表示該塊的結(jié)束。

但是，如在該示例中，多播傳送通常使用RTP/UDP來執(zhí)行，并且因此是不可靠的：通過內(nèi)容服務器104傳輸?shù)囊恍┌赡軟]有被客戶端接收到。盡管通常采用多播傳送，但使用重傳服務器以使用可靠的TCP傳輸來重傳客戶端所請求的丟失的包。盡管失敗仍然是可能的，但是由于在重傳中的丟失可以導致丟失的多播數(shù)據(jù)被傳送給客戶端，所以傳送得太晚以至于不能被有效地解碼。

因此，針對多播流，需要在發(fā)送塊在哪些包中結(jié)束的信令中的一些彈性，因為該單個包標簽可以駐留在丟失的多播包的一個中。所提出的方案在多播流的每個RTP包中包括附加信息，通過使用修改的頭部來給出關于塊編號以及塊邊界的信息。該附加信息可以以RTP有效載荷頭部格式被攜帶。

在本申請中，該附加信息包括兩個附加數(shù)值參數(shù)：CHUNK_INDEX(塊索引)參數(shù)和CHUNK_OFFSET(塊偏移)參數(shù)。CHUNK_INDEX參數(shù)和CHUNK_OFFSET參數(shù)都在圖7的RTP有效載荷頭部格式中示出。任意一個可以被單獨地或者組合地使用，以表示哪些塊存在在哪個RTP有效載荷中。

CHUNK_INDEX參數(shù)是序列號，其標識哪些塊被攜帶在哪些包中，并且還表示塊邊界。CHUNK_INDEX還用于將在多播流中的塊與在相關聯(lián)的單播流中的塊匹配。

在單播中，塊在清單文件中與URL相關聯(lián)以訪問該文件，但是在一些情況下，塊還被附加地與例如由蘋果公司HLS使用的EXT-X-MEDIA-SEQUENCE參數(shù)的數(shù)值參數(shù)相關聯(lián)。在本發(fā)明中，每個單播塊與通過清單文件的分析而確定的數(shù)值參數(shù)相關聯(lián)。該數(shù)值參數(shù)等于例如從EXT-X-MEDIA-SEQUENCE參數(shù)中得出的、在清單文件中的明確數(shù)值(如果存在明確數(shù)值的話)。否則該數(shù)值參數(shù)從該塊的URL中得出，該數(shù)值參數(shù)等于該塊的URL的數(shù)值文件名稱后綴部分，其中整個URL由文件路徑、根文件名、以及數(shù)值文件名后綴串聯(lián)組成。

當塊通過多播傳輸時，與該塊相關聯(lián)的數(shù)值以一對一的方式對應于與該塊相關聯(lián)的CHUNK_INDEX參數(shù)的值。這種一對一映射的示例是使用該數(shù)值作為CHNUK_INDEX的值。

下面是示例性的HLS清單-EXT-X-MEDIA-SEQUENCE表示與在該文件中的第一塊相關聯(lián)的值(2680)，并且因此剩下的值(2681和2682)是從該第一值得出的。注意，這些值與可從對應文件的數(shù)值后綴中得出的值(其在下面的示例中也是2680、2681和2682)一致：

#EXTM3U

#EXT-X-VERSION：3

#EXT-X-TARGETDURATION：8

#EXT-X-MEDIA-SEQUENCE：2680

#EXTINF：7.975，

https：//priv.example.com/fileSequence2680.ts

#EXTINF：7.941，

https：//priv.example.com/fileSequence2681.ts

#EXTINF：7.975，

https：//priv.example.com/fileSequence2682.ts

因此，該數(shù)值作為在單播中的種類(sort)的序列號，并且在多播流中，分配CHUNK_INDEX值也遵循相同的慣例，攜帶塊或者塊的一部分的包被分配了CHUNK_INDEX，該CHUNK_INDEX等于被分配給等效單播塊的序列號。內(nèi)容服務器104用該CHUNK_INDEX來標記每個包的有效載荷頭部。

舉例來說，如果在單播中塊序列號是2680，則對于多播流，用于攜帶該塊的所有包被標記了2680的CHUNK_INDEX。隨后當處理具有在單播中2681的序列號的下一個塊時，攜帶該塊的包具有2681的CHUNK_INDEX。

現(xiàn)在轉(zhuǎn)向CHUNK_OFFSET參數(shù)，在第一示例中，CHUNK_OFFSET參數(shù)采用隨給定塊的每個包增加1并且在新塊的第一個包中被設置為零的數(shù)值。在這一情況下，CHUNK_OFFSET參數(shù)可以隨后用于識別塊邊界，不僅通過用值零將包標識為塊的第一個，并且還在這種包丟失的情況下，通過CHUNK_OFFSET的值的減小來識別塊邊界。為了例示，針對攜帶塊的第一個包的CHUNK_OFFSET可被設置為0，并且隨后攜帶相同塊的一部分的第二個包將具有被設置為1的CHUNK_OFFSET，并且攜帶該相同塊的最后部分的第三個包將具有被設置為2的CHUNK_OFFSET。則在此后的攜帶新塊的下一個包將具有被重設為0或者低于2的任意值的CHUNK_OFFSET。因此，為0的CHUNK_OFFSET參數(shù)或者從先前CHUNK_OFFSET參數(shù)的簡單的減小發(fā)出新塊的開始的信號。

在第二個示例中，CHUNK_OFFSET參數(shù)可用于表示攜帶給定塊的全部先前包的有效載荷中的數(shù)據(jù)的總字節(jié)數(shù)。塊的第一個包將因此攜帶0的值，并且后續(xù)的包將攜帶單調(diào)增加的值。如在第一個示例中，通過等于零的CHUNK_OFFSET或者通過CHUNK_OFFSET的減小的值可以識別內(nèi)容塊邊界。

使用具有CHUNK_OFFSET參數(shù)的CHUNK_INDEX解決了失去攜帶單個塊的包的精確數(shù)量的不大可能解決的問題，這意味著僅CHUNK_OFFSET參數(shù)仍會如期望地遞增。CHUNK_INDEX作為塊的序列號，并且將會突出(highlight)丟失塊，以及提供與單播流塊的同步。

CHUNK_OFFSET參數(shù)表示攜帶在針對給定塊的先前包的有效載荷中的數(shù)據(jù)的總字節(jié)數(shù)的示例，實現(xiàn)了其他的優(yōu)點。具體地，如果多播流用于傳送呈ISO基本媒體文件格式的編碼的內(nèi)容，并且不具有在多播傳輸期間針對包丟失的重傳服務，或者如果該重傳失敗。對于基于包的傳輸流，任意丟失的包可以通過客戶端使用例如CHUNK_INDEX來搜索下一個傳輸流塊的開始來處理。但是，如果該內(nèi)容是ISO基本媒體文件格式，則這就沒那么簡單了，因為該編碼的視頻內(nèi)容被封裝，并且需要具有關于該塊的開始的偏移值的索引表，從而對其解包。因此，如果一些數(shù)據(jù)丟失了，則除非知道丟失數(shù)據(jù)的量，否則丟失數(shù)據(jù)之后的數(shù)據(jù)不能用作偏移值不再是有效的。通過將CHUNK_OFFSET參數(shù)設置為將字節(jié)數(shù)表示關于塊的內(nèi)容的數(shù)據(jù)，包的丟失將不會導致未知量的丟失信息，而丟失信息的精確量可以被推出，并且在索引表中的偏移仍然可用于處理該內(nèi)容塊的后續(xù)的包。

通過多播流生成器230來處理針對多播傳輸?shù)腎P包的標記和生成，并且在步驟308中執(zhí)行該IP包的標記和生成。通過輸出接口234輸出獲得的多播流，在該輸出接口234多播流可以被傳送到網(wǎng)絡。

在視頻的塊的傳輸級的級別上的標記確保了系統(tǒng)可以容忍在視頻規(guī)格上的任意改變。例如，即使使用了新的視頻/音頻格式，使用這一方法仍然可以確定塊邊界。

更具體地，在傳輸級上標記塊邊界避免了需要更深入地處理該塊數(shù)據(jù)，并且因此不需要知道視頻和音頻比特流規(guī)格，以及不需要知道傳輸容器格式，例如MPEG-2傳輸流。其因此支持另外的和新的視頻和音頻格式。此外，在音頻和/或視頻被加密的情況下，在單播傳送和多播傳送之間的切換可以被無縫執(zhí)行，而無需客戶端或者其他處理裝置知道解密密鑰。

現(xiàn)在將會參考客戶端中的一個來探究發(fā)起單播流、并且隨后切換到多播流的處理。

從客戶端向內(nèi)容服務器104針對與內(nèi)容相關聯(lián)的清單文件發(fā)出的初始請求而開始處理。內(nèi)容服務器104返回清單文件，清單文件包括標識該編碼的內(nèi)容在數(shù)據(jù)存儲器224中的位置的信息。

客戶端隨后開始從內(nèi)容服務器104或者更具體地從數(shù)據(jù)存儲器224(或者網(wǎng)絡服務器)，通過單播以HTTP請求的形式，針對在該清單中設定的特定塊來請求編碼的內(nèi)容塊。因此，客戶端有效地將該內(nèi)容從寄存編碼的內(nèi)容的網(wǎng)絡服務器中拉出。所請求的塊在該示例中是單獨的傳輸流塊。

客戶端還可定期從內(nèi)容服務器104請求更新的清單。當內(nèi)容服務器104針對任意給定內(nèi)容接收到進一步的傳輸流塊時，內(nèi)容服務器104可以更新與該內(nèi)容相關聯(lián)的清單文件。建立更新的清單，從而反映從內(nèi)容生成器102接收到的這些附加塊，并且當被請求時提供給客戶端。

不久，切換邏輯可以決定使得當前被單播檢索到的內(nèi)容通過多播也是可用的。注意，該內(nèi)容對于從數(shù)據(jù)存儲器224的單播將仍是可用的，因為可以具有不能夠接收多播，或者沒有被配置為接收多播的客戶端。內(nèi)容服務器104采用切換到多播的指示符來更新該清單。在.m3u8清單文件的情況下，該指示符可以是以下形式：

#EXT-X-SWITCH：udp：//239.1.2.3：4321

其中，EXT-X-SWITCH表示具有一些種類的切換，并且udp：//239.1.2.3：4321表示其是多播，給出了多播地址239.1.2.3，端口號4321。

同時，多播流生成器230將開始生成如上所述的、具有識別塊邊界的特定傳輸層包頭部的多播流?；谠谏鲜銮鍐沃械倪@一指示符，通過在端口4321的、具有地址239.1.2.3的輸出接口來輸出所獲得的多播流。

客戶端將及時請求包括切換指示符的更新的該清單文件。但是，如果立即傳送切換到多播的信號是非常重要的，則只要該清單已經(jīng)被更新，內(nèi)容服務器104就可以在內(nèi)容塊中包括事件消息，其通過單播傳送以發(fā)送對該清單的更新的信號?？蛻舳丝梢噪S后請求該更新的清單。

針于MP4文件的事件消息在ISO/IEC 23009-1中定義，并且攜帶在事件消息框(Event Message box)(‘emsg’)中。

針于傳輸流的事件消息在ISO/IEC 13818-1：2013Amd.4中定義，其中，定義了具有PID值0x0004的傳輸包被用于攜帶自適應流傳輸信息數(shù)據(jù)，其有效載荷格式與針對MP4文件的有效載荷格式相同，并且因此還被規(guī)定在ISO/IEC 23009-1中。

當讀取更新的清單文件后，客戶端將知道多播組是可用的，并且試圖通過發(fā)出IGMP加入請求來加入其中。

客戶端已經(jīng)讀取和知道已經(jīng)被傳送的當前單播塊的塊序列號或者索引，并且將針對CHUNK_INDEX參數(shù)檢查當前流傳輸?shù)亩嗖チ?，以識別將要從該源傳送的后續(xù)塊(多個后續(xù)塊)。

當客戶端首次加入多播流時，其接收的第一個數(shù)據(jù)可以不是來自于塊的開始的數(shù)據(jù)?？蛻舳诵枰R別在多播流中的、對應于已經(jīng)接收到的單播數(shù)據(jù)中的點的點。一個這樣的點是塊的開始，如上所述，通過觀察CHUNK_OFFSET參數(shù)的值的減小或者CHUNK_INDEX參數(shù)的改變，來在本發(fā)明中識別出所述一個這樣的點?？蛻舳送ㄟ^與在多播中的CHUNK_INDEX參數(shù)的值中的變化類似的、在與單播塊相關聯(lián)的數(shù)值參數(shù)的變化，來識別在已經(jīng)接收的單播數(shù)據(jù)中的相同點?？蛻舳颂幚韱尾K直到該識別的點，并且隨后從該相同的點開始處理多播塊。

參數(shù)可以用在多播流中，以表示該多播流將要停止，以及應發(fā)起針對該單播流的清單的請求。

一種發(fā)送多播傳送將很快變?yōu)椴豢捎玫男盘柕姆绞绞?，在RTP有效載荷頭部中傳送該多播傳送將很快變?yōu)椴豢捎?。這可以作為在每個RTP包中的一個比特標簽來發(fā)送信號，當該比特標簽設置為“1”時表示該內(nèi)容塊是最后要被多播傳送的內(nèi)容塊；或者其可以以表示包括當前的塊的、將通過多播傳送的塊的數(shù)量的多比特數(shù)值來發(fā)送信號，該多比特數(shù)值的零值表示多播傳送的結(jié)束沒有逼近。

當客戶端正在通過單播接收內(nèi)容時，其針對清單更新向內(nèi)容服務器發(fā)送定期HTTP GET請求。這些請求可以通過HTTP日志由切換邏輯獲得，并且用于幫助確定是否以及何時在單播和多播之間切換。但是，當通過多播傳送時，客戶端不發(fā)出定期請求，因為客戶端所需要的用于切換回單播的所有信息被嵌入到多播流中的標簽包中。

因此，在本發(fā)明的另一示例中，客戶端被配置為，針對對清單的更新而向內(nèi)容服務器104發(fā)出定期HTTP‘HEAD’請求。HEAD請求通常返回與所請求的文件相關聯(lián)的元數(shù)據(jù)，在此情況下是清單文件。而清單文件在多播流期間并不是實際需要的，迫使客戶端定期發(fā)送HEAD請求同時接收多播流，給內(nèi)容服務器104提供了客戶端積極接收該多播流的反饋。因此，切換邏輯能夠確定網(wǎng)絡中有多少客戶端正在積極通過多播通道接收任意給定內(nèi)容。

通過在內(nèi)容服務器104處將HEAD請求的數(shù)量與(通過單播接收客戶端提出用于請求該內(nèi)容的具體塊做出的)GET請求的數(shù)量進行比較，切換邏輯232可以在任意時間確定有多少客戶端正在接收哪個內(nèi)容，以及是否使用了多播或者單播。根據(jù)該知識，切換邏輯232針對具體段的內(nèi)容能夠做出多播或者單播的合適選擇。

迫使接收客戶端發(fā)送HEAD請求而不是GET請求，允許內(nèi)容服務器容易在來自單播(GET)的反饋和來自多播(HEAD)的反饋之間區(qū)分。

此外，這一方法的另一個主要優(yōu)點是，其獨立于任意較低等級的多播邏輯。例如，即使一個人對IGMP加入多播流做了計數(shù)，也沒有辦法說出哪些客戶端仍然在消費該內(nèi)容?？蛻舳丝擅鞔_地離開多播組，但是它們還可以簡單地停止監(jiān)聽。這一方法提供了解決方案。

雖然已經(jīng)結(jié)合使用單播或者多播直接將內(nèi)容流傳輸?shù)娇蛻舳嗣枋隽松鲜鍪纠?，但是提出了使用客戶端代理的另一可選的的示例。客戶端代理可以駐留在位于客戶端的合適配置的路由器或者集線器中，其可以給多于一個的客戶端提供代理服務。客戶端代理的主要目的是，通過多播接收內(nèi)容塊數(shù)據(jù)，本地地存儲該內(nèi)容塊數(shù)據(jù)，并且在通過單播可用的時從客戶端代理將其廣播到客戶端。這將使得多播傳送用于傳送到客戶端代理，獲得多播傳送的網(wǎng)絡效率效益，并且能夠使用不太適合通過多播傳送數(shù)據(jù)的技術(例如WiFi)，來最終傳送到可能不支持多播和/或連接到代理的客戶端。

一般來說，應當注意到，雖然上面描述了本發(fā)明的實施方式，但是還存在可對所描述的示例作出的多種變化和修改，而不偏離由所附權(quán)利要求限定的本發(fā)明的范圍。本領域技術人員將能夠辨別對所描述的示例的修改。