專利名稱：基于因特網協議的分布式實時多媒體流結構的制作方法
技術領域：
本發明通常涉及聯網的多媒體系統。更特別地，本發明涉及一種媒體傳遞系統，用于通過一個多路廣播網絡將媒體選擇傳遞到一個或多個媒體客戶機。
隨著因特網的爆炸性發展，關于使用因特網以及其它基于因特網協議的網絡來傳遞(delivery)多媒體選擇，例如視頻和音頻材料的興趣也逐漸提高。交互式電視、點播電影以及其它多媒體推進(push)技術屬于更有前途的應用。
因特網是一個提供最大努力的(best effort)傳遞服務的無連接的網絡。數據的包以攜帶目標接收器的地址的數據報的形式被路由。在發送器和接收器之間不需要一個特定的連接，因為網絡上的所有宿主機節點包含固有的能力，能將數據報點到點發送直到實現傳遞。這種數據包傳遞方案作為一個最大努力的傳遞系統來構造，其中不保證數據包的傳遞。數據包可以通過不同的路由傳遞以盡力增大傳遞的可能性。因而，如果網絡上的一個節點擁塞，隨后的數據報可以改變路由以避開該擁塞的節點。這意味著數據數據包無法固有地具有一個能保證的到達時間。即使對應單條消息的包也可能在接收時無序。這個事實嚴重影響了多媒體數據傳遞的確定性。
在許多情況下，多媒體數據需要實時傳遞。在音頻或視頻數據的情況下，代表一個特定媒體選擇的數據流需要以正確的時間順序傳遞，以允許用戶在音頻或視頻選擇被傳遞時能“實況”重放。顯然，如果數據包由于采用不同的傳遞路由而無序傳遞，則多媒體客戶機(例如，一個用戶的交互式電視)處的重放將會混亂。
實時協議(RTP)是用于在因特網(或其它基于IP協議的網絡)上傳遞實時內容的當前事實上的標準。實時協議用一種實時請求能夠直接用于數據傳遞的框架取代了常規的傳遞控制協議(TCP)。當前，RTP標準支持第一類型的消息，即用于攜帶媒體內容數據或流型數據的消息。典型地，一個單獨的協議，實時控制協議(RTCP)與RTP一起使用，以通過用于會話管理、速率適應等的控制消息。
實時協議能夠用于在計算機網絡上傳遞多媒體流型數據，現有結構尚未證實其足夠強健以至能利用例如由因特網提供的最大努力的網絡服務以提供高質量的表現。本發明通過利用一種能夠從多源并且經過多個分布路徑冗余地提供流型數據的分布式媒體推進結構解決了這個問題。媒體推進引擎(engine)具有相連的媒體存儲單元，它將流型數據存儲為非分層的子流成分群。由比所有成分少的成分能夠重構為一個重構流，使得重構中使用的成分數越多，重構流的質量就越高。
常規的系統使用的分層編碼方案將一些成分視為比其它成分重要。因而，常規的系統典型地需要擴展相當多的資源以保證更重要的成分總是被傳遞。相反，本發明的媒體傳遞系統使用的一種非分層編碼方案，多描述(description)編碼(MDC)對所有的成分同等看待。因而，沒有特定的資源需要分配以保證給定的子流成分群被傳遞。自然地，傳遞的成分數越多，獲得的質量越高；另一方面，不象常規的分層編碼，任何給定的單個包的丟失不會略微地降低信號質量。
分布式媒體傳遞系統還使用了一種分布式接納控制系統。媒體客戶機與一單個接納控制單元聯系以請求一個給定的媒體選擇，但是此后接納控制決定由媒體推進引擎本身以分布式方式處理。接納控制單元將請求傳達到分布在網絡中的多個媒體推進引擎，并且這些推進引擎分別地決定它們是否能夠參與多路廣播會話。因而，各個媒體推進引擎估計本地的業務擁塞以決定是否它能夠提供所請求的數據流。因而接納控制單元不涉及直接決定應該允許哪個媒體推進引擎進入一個多路廣播組會話。接納控制單元以分布式的方式簡單地分配多路廣播組會話地址，并且然后允許接納步驟自主進行。
為了對本發明、其目的以及優點有更完整的理解，必須參考以下說明書以及附圖。


圖1是顯示本發明的一個首選實施例的網絡數據報；圖2是一個詳細的網絡數據報，顯示如何利用非分層多描述編碼在網絡上分布兩個不同的數據流(X和Y)；圖3是顯示多描述編碼(MDC)的一個實施例的數據流程圖；圖4是顯示TCP/TP結構以及顯示RTP結構可以如何并入一個基于IP的系統的一個層數據報；圖5是顯示根據實時協議(RTP)的包格式的詳細的格式數據報；圖6是顯示根據本發明的訪問接納和會話管理的一個網絡數據報；圖7是顯示在多路廣播IP網絡上的媒體推進引擎和多媒體之間的信息流的一個詳細的網絡數據報；圖8是顯示源成分服務器重新分布步驟的一個網絡數據報；以及圖9是顯示如何修改實時協議(RTP)以提高可靠性的一個協議數據報。
參考圖1，一個代表性的分布式聯網的多媒體系統以10表示。多個媒體推進引擎12可通過多路廣播網絡14訪問。當前首選的實施例設計為在一個使用因特網協議(IP)的網絡上工作；然而，本發明的原理可以容易地擴展到使用其它協議的網絡。網絡14還可被一個或多個多媒體客戶機16訪問，如圖所示。一個可通過網絡14訪問的接納控制單元18，執行某些接納控制功能，主要以啟動(initiate)或開放一個多路廣播組會話。接納控制單元包括一個目錄服務系統20。目錄服務系統包含一個數據庫記錄，顯示哪些多媒體選擇可由多個媒體推進引擎傳遞。盡管接納控制步驟涉及開放一個多路廣播組會話，但是它實際上是以如下面將要更充分地討論的分布式方式執行的。
分布式媒體傳遞系統通過開放媒體客戶機與具有可傳遞的被請求的媒體選擇的媒體推進引擎之間的一個多媒體組會話，從一個多媒體客戶機響應傳遞請求。典型地，多媒體推進引擎將參與同時傳遞與被請求的選擇相應的流型數據。多媒體客戶機是一個執行提供(presentation)功能的用戶宿主機。它從由參與的媒體推進引擎傳遞的不同的流成分重構一個最終的流。每個媒體推進引擎有其自身的用于流成分數據的數據存儲器，并且這些數據存儲系統能夠被具有可安裝的和透明的存儲和恢復功能的一個適當的分布式文件系統作為媒介。
分布式媒體傳遞系統的一個重要方面是流型數據存儲在媒體推進引擎的方式。不象傳統的以分層方式存儲多媒體數據的系統，本發明利用一種非分層編碼方案，這里稱為多描述編碼(MDC)。多描述編碼將視頻和/或音頻流分離為稱作成分的子流。則每個成分能被編碼并且在網絡上與所有其它成分獨立地傳遞。多媒體客戶機16上的客戶軟件能夠從成分的任意子集中集合一個重構流。因而重構流能從少于所有成分的成分中被集合。重構中使用的成分數越多，重構流的質量就越高。
利用這種非分層編碼在固有不可靠的網絡上傳遞流型數據能提供驚人強大的媒體傳遞，特別是當媒體推進引擎參與傳遞時。正如將更充分地討論的那樣，媒體推進引擎本身以分布式方式控制多路廣播組會話接納進程，按照維持高服務質量的需要增加或減去媒體推進引擎。因而，當多路廣播網絡14呈現低業務量擁塞時，僅需要少數媒體推進引擎以提供所有MDC編碼流的成分。即使一些成分不以及時方式傳遞，多媒體客戶機仍然能夠重構用于提供的流(以一定程度的降低的質量)。如果網絡業務量擁塞程度高，媒體推進引擎相互協商以增加附加的媒體推進引擎。因為接納控制進程步驟是分布式的，單獨的媒體推進引擎能夠估計它們自己本地的業務量擁塞，并且將依靠本地業務量條件，因而參與或者不參與組會話。
圖2更詳細地顯示多描述編碼如何工作。在圖2中，兩個用X和Y表示的多媒體流通過多個媒體推進引擎存儲。這些流被斷開成子流成分，用下標X1,X2,…,Xn；Y1,Y2,…,Yn表示。注意到通過多個媒體推進引擎存儲的子流成分對于每個引擎沒有必要是相同的。因而媒體推進引擎12a存儲成分X1,X6和Y1。同樣地，媒體推進引擎12b存儲成分X2,X7和Y2。
多媒體客戶機通過以正確的順序累加正確的子流成分來重新集合感興趣的流型數據。因而多媒體客戶機16a重構圖示的流X，而多媒體客戶機16b重構圖示的流Y。各個子流成分從不同的媒體推進引擎通過不同的路徑到達多媒體客戶機沒有關系。
當前首選的多描述編碼方案的結構如圖3所示。原始的多媒體數據流(例如視頻和/或音頻數據)被分解為多個子信號，并且然后每個子信號被獨立地壓縮。如上所述，分解是非分層的，使得可接受的信號能夠從任意一個子信號恢復，通過附加的子信號能夠實現改進，并且當所有子信號正確接收時實現理想的重構。此外，更可取的是使綜合壓縮增益最大，只要滿足以上三個標準。
分解原始信號的一個途徑是將每個子信號構造為原始信號的一個簡化的分解表述。如圖所示，這可以通過使原始信號經過一個低通濾波器后接下采樣(downsampling)來實現。因而子信號僅在采樣位置上不同。如果需要，這種分解能夠通過一個包括前置濾波器及其變型的濾波器系列獲得。
應選擇前置濾波器以抑制低采樣子信號中的混疊成分。這有助于降低子信號編碼所需的比特率，并且有助于使得能夠從單個子信號恢復一個可接受的圖象。
應進一步選擇前置濾波器使其不完全消除高頻成分。如果高頻成分被完全消除，則即使所有的子信號都存在，也將無法恢復原始信號中的那些成分。因而濾波器應該抑制，但不是完全消除高頻成分。
數學上，子流成分重構為一個重構流包括使關聯所有子流中的采樣以及原始流中的采樣的矩陣方程轉置。典型地，這可能包括一個大的矩陣方程，以及占用大的計算量和存儲空間的轉置。處理這個計算重任的一個途徑是使用一種塊遞歸重構方法。在遞歸步驟中的每一步，原始流中的一個2×2采樣的塊基于接收到的子成分流中的相當于四個相應的采樣被恢復。當然，其它計算技術可以用來達到相同的結果。關于利用多描述編碼以非分層方式編碼和解碼的更多信息，見“Robust Image Coding andTransport in Wireless Networks Using a Non-HierarchialDecomposition”，Yao Wang and Doo-man Chung。Mobile MultimediaCommunications；Goodman(Plenum Press)MDC編碼的子流利用實時協議(RTP)用于內容傳遞以及實時控制協議(RTCP)以實現流控制，在多路廣播網絡上以數據報傳遞。這些協議能夠與許多因特網應用程序使用的流行的TCP/IP協議自然地共存。圖4通過五個實體如何相互通信的一個例子提出了這些協議的一個綜述。在圖5中，實體30-38利用因特網普及的層結構相互通信。當然，可以理解圖4只打算顯示當前首選的實時協議(RTP)如何并入一個可能的結構方案。盡管實時協議是當前首選的，這里不打算作為本發明在其更廣泛的方面的一個限制。相反，可以適當地使用其它消息傳遞協議。
在圖4中，每個通信實體30-38以一個層結構顯示，底部有物理層且頂部有應用層。實體30在物理級(level)使用以太網協議與實體32通信。實體32與實體34在物理級使用ATM協議通信。以同樣方式，實體34使用以太網協議與實體36通信，并且實體36使用PPP協議與實體38通信。再一次，選擇在此顯示的物理層通信協議不打算作為如附加權利要求書所述的本發明的一個限制。
物理層上面是因特網協議(IP)層。IP協議使物理層或傳遞層與應用層分離。IP協議支持信息的包以數據報傳遞和接收的無連接的通信。注意到在圖4顯示的例子中所有的通信實體都使用IP協議。
在IP協議的上一層顯示了兩個不同的更高水平的協議，TCP協議和UDP協議。再一次，該圖示僅打算作為一個可能的配置的一個例子。UDP協議或用戶數據報協議代表一個簡單的傳遞協議。它不試圖保持它傳遞消息的順序。TCP協議或傳遞控制協議提供更高水平的可靠性，還確保數據報以正確的順序傳遞。TCP協議使用一個確認系統以確保所有的數據報以以正確的順序傳遞。TCP協議包括一個用于重新傳遞未確認的包的機構。這個確認/重新傳遞技術保證正確的包傳遞，但是它不保證包實時傳遞。因而TCP協議通常不適用于傳遞實時數據例如多媒體視頻和/或音頻數據。
實時協議(RTP)用應用程序能夠直接使用的一個簡單的框架取代了更復雜的TCP傳遞協議。RTP協議簡單地忽略丟失的數據，而不是提供一個會引入傳遞延遲的丟失數據探測和重新傳遞機構。RTP協議還不典型地涉及包傳遞的順序。協議假定它上面的應用層將修正任何錯序的數據。RTP協議與許多不同的編碼標準例如MPEG、JPEG和H.261兼容。
在圖4顯示的例子中，實體30和38都運行RTP協議。因而流型數據能夠從實體30通過包括實體30、32、34、36和38的網絡提供給實體38。
RTP協議設計用于多路廣播業務。多路廣播是消息可以以指定的群傳遞到許多不同的接收器的一種消息廣播形式。多路廣播地址識別接口群，經常包括屬于不同系統的多接口。當一條消息具有一個多路廣播目的地址時，網絡努力將其傳遞到群中的所有接口。這個功能使一個系統一次產生一條消息并且使該消息傳遞到許多不同的接收器。
除了將數據包傳遞到多接收器以外，多路廣播網絡還典型地支持從消息接收器的反饋。典型地，多路廣播組會話中的所有參與者都能夠接收這些反饋消息。這些反饋消息一般用于實時業務控制，遵循一個有關的實時控制協議(RTCP)。在某些方面，RTCP是RTP的一個可選擴展。當前首選的實施例使用RTCP包在參與組多路廣播會話的實體之間傳遞流控制和會話管理信息。
圖5顯示RTP包格式。注意到包包括在以正確的時間順序重新集合包時使用的一個順序號和時間戳記(stamp)。
圖6和圖7顯示在一個多路廣播組會話中，多媒體客戶機、接納控制單元以及媒體推進引擎如何相互通信的細節。確切地，圖6顯示首選實施例的基本消息流和通信順序。圖7給出在將子流成分數據報從媒體推進引擎發送到多媒體客戶機時如何使用RTP協議和RTCP協議的一個更詳細的圖示。
首先參考圖6，多媒體客戶機16將一條單路廣播TCP協議消息發送到接納控制單元18，請求開始傳遞特殊的媒體選擇。接納控制單元18查詢其目錄服務系統20以確定被請求的選擇(即被請求的流)是否在網絡上。假定流存在，接納控制單元將一條流開放消息傳遞到那些具有被請求的選擇的至少若干子流成分的媒體推進引擎12。這個開放流請求被發送到所有媒體推進引擎。那些發現自己能夠服務被請求的流成分的媒體推進引擎共同地進入僅在服務和接收該特定流的宿主機之間的多路廣播會話管理和流控制會話。參與的媒體推進引擎和參與的多媒體客戶機從接納控制單元獲得這個控制多路廣播組會話需要的地址。此后，接納控制單元有效地退出會話，允許隨后的會話管理和流控制消息僅在多路廣播組成員(即多媒體客戶機和所有相應的媒體推進引擎)之間交換。這降低了接納控制單元18上的管理費用(overhead)。
接納控制單元產生多路廣播會話使用的一個多路廣播D級地址。該地址可以選自一個可用的多路廣播地址實體庫。因而接納控制單元負責管理多路廣播地址的分配。當一個多路廣播會話結束時，接納控制單元將多路廣播會話地址返回到可用地址庫。
因而多路廣播組會話一旦啟動，那些能夠支持子流成分的媒體推進引擎將通過發送單路廣播RTP會話流型數據到多媒體客戶機16這樣做。通過RTCP協議，這些媒體推進引擎可以相互通信，以按照維持高質量服務的需要加入或離開一個多路廣播組會話。
參考圖7，媒體推進引擎和多媒體客戶機通過網絡在兩個不同的水平通信。如虛線所示，一個單路廣播RTP會話將多媒體流型數據傳遞到多媒體客戶機。同時，按照需要，媒體推進引擎和多媒體客戶機相互發送RTCP報告，確切地除了任何適當的流控制命令和其它會話管理命令(例如開始推進、暫停、繼續)外還有發送器報告和接收器報告。RTCP控制信號在圖7中用雙向實線表示。
必要地，接納控制單元發送流開放消息后，每個媒體推進引擎查詢其相連的媒體存儲系統以決定其是否能夠服務被請求的流成分。如果是，則媒體推進引擎加入指定的多路廣播組。否則它不參與多路廣播會話(除非稍后被請求)。媒體推進引擎一旦加入多路廣播組，它就利用RTCP協議參與通信，由此所發送數據和所接收數據的統計資料在組成員之間交換。如上所述，接納控制單元不需要參與這些通信并且因此它將保持暫停除非另一個會話的請求出現或直到當前會話請求終止。
有效地，系統提供一個分布式接納控制系統，其中，參與的組成員共同地和分別地做出接納控制決定。這種分布式方法的一個好處是本發明能夠并入智能機構，以防止網絡擁塞和提高服務質量，盡管多路廣播網絡是不保證實時傳遞的最大努力的網絡。
最大努力的網絡，特別是那些缺乏復雜業務和用戶控制合同的網絡，遇到頻繁的擁塞。這種擁塞能夠導致實時數據很大程度延遲的損失。如前面討論的，遲傳遞的實時數據被有效地視為未傳遞。數據持續地流入網絡的一個擁塞的節點會使擁塞更嚴重。本發明使用有關時間感應傳遞的RTCP協議發送器報告和接收器報告，作為一個給定節點可能需要重新估計當探測到擁塞時正傳遞的成分數的一個指示。
圖4顯示這是如何實現的。多媒體客戶機16已經請求了X實時流型數據，包括子流成分X1、X2、X3和X4。假定圖7中的媒體推進引擎12正遇到本地業務擁塞，使得子流成分推遲到達多媒體客戶機16。多媒體客戶機的RTCP接收器報告通報媒體推進引擎12(以及所有參與組會話的其它媒體推進引擎)來自媒體推進引擎12的成分數據的某個百分比。媒體推進引擎12分析這些報告并且停止發送一個選擇的成分，在這種情況下是X3，由此減少流經其擁塞節點的業務量。因而，經過調整，媒體推進引擎12僅將成分X1、X2和X4提供給多媒體客戶機。當參與組會話的其它媒體推進引擎接收同樣的發送器和接收器報告時，如果其它媒體推進引擎能夠提供這個丟失的成分，媒體推進引擎12丟失的X3成分就可以得到補償。否則，服務質量將如上所述而略微降低。
圖8顯示如何通過對要被發送的子流成分作本地調整來有效地重新分配數據流。在顯示的實施例中，假定在從媒體推進引擎12b提供子流成分的數據路徑的某處有本地擁塞。因而RTCP發送器和接收器報告將指示先前由媒體推進引擎12b發送到多媒體客戶機16的成分的某部分由于本地擁塞而丟失或延遲。在顯示的實施例中，丟失的成分碰巧也在媒體推進引擎12a的存儲系統中。媒體推進引擎12a能夠將丟失的成分有效載荷重新傳遞到多媒體客戶機，或簡單地調整將在將來的實時數據事務(transaction)中傳遞的成分群。在丟失的有效載荷被另一個媒體推進引擎重新傳遞的情況下，多媒體客戶機應該提供足夠的緩沖以允許丟失的成分在流被重構并提供給用戶之前與先前傳遞的成分一起被重新傳遞。在系統僅改變用于將來傳遞的成分群的情況下，這種變化構成一個可縮放的(scalable)服務器成分重新分配機構。這個機構通過改善給多媒體客戶機的數據流提供，提高了服務的改進的質量。
盡管上述實施例通常適用于大多數媒體傳遞應用，但也有一些系統不能容忍質量上的即使是略微的降低。這些系統包括高質量廣播視頻分布。在這些更苛求的應用中，前述首選實施例的系統可加以修改，以使用一個附加的可靠性機構用于實時成分。在這種情況下，實時協議可加以修改或增加，以允許丟失的實時有效載荷的重新傳遞。這個“可靠的RTP”在圖9中顯示。媒體推進引擎使用實時協議與RTP堆棧通信。在這種情況下假定第一和第三成分被接收但第二成分丟失了。從RTP堆棧有一個立即拒絕確認(NACK)，告之媒體推進引擎第二有效載荷沒有接收到。媒體推進引擎則重新傳遞所需的有效載荷并且RTP堆棧將所需的有效載荷放入數據緩沖器中的正確位置。客戶機應用程序則從數據緩沖器讀數據。任何復制的包將撤消(drop)并且任何過分延遲的包也可能被撤消。
由前述可以理解本發明提供了一個媒體傳遞系統結構，它使用一個分布式、聯網的技術用于在一個最大努力的網絡上傳遞流型數據。當服務器的復雜性隨客戶機數量線性增加時，該結構可以容易地縮放、增大或減小。因而該結構是一個完全分布式的、緊密連接的并行結構，能夠提供簡單的且強健的服務。
通過使用多描述編碼(MDC)和多路徑傳遞，本發明能夠提供一個高質量的服務，而不采取延遲產生傳遞再試技術。因而本發明將容易地與現有的用于數據傳遞的實時傳遞協議(RTP)和用于會話管理的實時控制協議(RTCP)、速率適應等等一起工作。當遇到擁塞時，傳遞可以減慢但不中斷，歸功于多描述編碼和組會話的參與者可以從組中增加或去除的方式。流的流控制也可通過這些相同的機構控制，以便一旦探測到擁塞可阻止或減少網絡擁塞。
因此除了視頻和音頻流型數據外，本發明理想地適用于多媒體選擇的傳遞。本發明將容易地支持多比特率的數據流并且能夠提供一定比特率和可變比特率的服務。
雖然本發明用其當前首選的實施例描述，但是要理解到本發明能夠在不偏離如附加的權利要求書中所述的精神的條件下做某種修改或變化。
權利要求
1．一種分布式媒體傳遞系統，用于在一個多路廣播網絡上將媒體選擇傳遞到一個媒體客戶機，包括可通過所述網絡訪問的多個媒體推進引擎，所述推進引擎每個具有相聯的媒體存儲單元，用于存儲代表可用于傳遞的媒體選擇的流型數據；所述媒體存儲單元被配置，以存儲所述流型數據，作為能夠從比所有所述成分少的成分重構為一個重構流的一個非分層的子流成分群，使得重構中使用的成分數越多，重構流的質量越高；以及可通過所述網絡訪問的一個接納控制系統，所述接納控制系統包括一個用于存儲能夠被每個所述媒體推進引擎傳遞的媒體選擇的等同性的目錄，所述接納控制系統工作，響應來自一個媒體客戶機的一個給定的媒體選擇的一個請求，以在所述媒體客戶機和至少一部分具有能用于傳遞的給定媒體選擇的所述媒體推進引擎之間開放一個多路廣播組會話，由此參與所述多路廣播組會話的每個所述媒體推進引擎向所述網絡提供相應于給定媒體選擇的子流成分，用于傳遞到所述媒體客戶機并且被所述媒體客戶機重構。
2．權利要求1的媒體傳遞系統，其中所述接納控制系統是一個通過所述媒體推進引擎之間的交互作用至少部分限制的分布式系統。
3．權利要求1的媒體傳遞系統，其中所述媒體推進引擎與所述網絡通過不同的通信路徑通信。
4．權利要求1的媒體傳遞系統，其中所述網絡是一個能提供最大努力的傳遞服務的無連接的網絡。
5．權利要求1的媒體傳遞系統，其中所述網絡是因特網。
6．權利要求1的媒體傳遞系統，其中參與所述多路廣播組會話的所述媒體客戶機和所述媒體推進引擎使用實時傳遞協議(RTP)用于數據傳遞。
7．權利要求1的媒體傳遞系統，其中參與所述多路廣播組會話的所述媒體客戶機和所述媒體推進引擎使用實時控制協議(RTCP)用于會話管理。
8．權利要求1的媒體傳遞系統，其中至少部分所述子流成分通過幾個媒體推進引擎復制。
9．權利要求1的媒體傳遞系統，其中至少部分所述子流成分通過第一和第二媒體推進引擎復制，并且其中所述傳遞系統進一步包括擁塞處理系統，用于識別所述第一和第二媒體推進引擎的哪一個是擁塞的原因，以及用于自動調用所述第一和第二媒體推進引擎的另一個參與所述多路廣播組會話。
10．權利要求9的媒體傳遞系統，進一步包括與所述媒體客戶機相聯的數據緩沖系統，用于在重構之前存儲子流成分。
11．權利要求1的媒體傳遞系統，其中所述接納控制單元進一步工作，響應來自所述媒體客戶機的結束一個多路廣播組會話的請求，以指示參與所述多路廣播組會話的所有媒體推進引擎終止會話。
12．權利要求1的媒體傳遞系統，其中所述接納控制系統包括一個保持在調用多路廣播組會話中使用的一個多路廣播會話地址庫的接納控制單元，并且其中所述接納控制單元分配選自所述庫，被所述多路廣播組會話使用的一個指定的多路廣播會話地址。
13．權利要求12的媒體傳遞系統，其中所述接納控制單元進一步工作，響應來自所述媒體客戶機的結束一個多路廣播組會話的請求，以將所述指定的多路廣播會話地址返回到所述庫。
14．權利要求12的媒體傳遞系統，其中參與所述多路廣播組會話的所述媒體客戶機和所述媒體推進引擎交換流控制消息而不涉及所述接納控制單元。
15．權利要求1的媒體傳遞系統，其中在參與所述多路廣播組會話的所述媒體客戶機和每個所述媒體推進引擎之間有包括實時流成分數據的數據報的單路廣播流。
全文摘要
多媒體推進引擎通過一個具有多傳遞路徑的多路廣播網絡與多媒體客戶機通信。代表用于傳遞的媒體選擇的流型數據利用一種非分層編碼技術通過多媒體推進引擎進行分布,在這種技術中,數據用子流成分群表示,能夠由比原始流型數據的所有成分少的成分重構。重構中使用的成分數越多,由重構流提供的服務質量就越高。在接納控制單元打開多路廣播流的地方,組多路廣播會話的接納控制以一種分布式的方式管理,所有隨后的接納控制的決定由媒體推進引擎本身做出。
文檔編號H04L12/64GK1216422SQ98121398
公開日1999年5月12日 申請日期1998年10月21日 優先權日1997年10月30日
發明者丹尼斯·布什米奇 申請人:松下電器產業株式會社