用於數字內容的自適應虛擬廣播的方法和系統與流程
2023-05-29 11:51:26 8
相關申請的交叉引用
本申請要求於2014年12月26日提交的美國臨時專利申請no.62/096,938的優先權，由此通過引用將其全文公開併入本文。
本發明一般涉及用於在底層網絡的節點之間傳送數字內容的覆蓋網絡架構，更具體地，涉及一種優化數字內容在沿著覆蓋網絡的節點之間的路由的虛擬廣播系統，該覆蓋網絡是基於對底層網絡內的組件互連處的頻繁改變的擁塞級別的預報來動態地重新配置的。
背景技術：
網絡擁塞
隨著有線和無線網絡流量持續呈指數增長，網絡中組件之間的共享鏈路或互連的有限容量正變為越來越相關且令人不安的問題。此外，因為這些共享鏈路處的擁塞級別是動態的，並隨著網絡流量的下降和流動而遭受極大的不穩定性，所以這種擁塞難以在任何給定的時間進行測量，且甚至在近期也特別難以預測。
這個問題有點類似於人口稠密地區共享道路和高速公路的交叉路口處的交通擁堵問題。雖然現有的gps導航和交通控制系統測量這些路口的當前擁塞狀態並計算各個司機繞過這種擁堵的重新路由的最佳路徑，但這些系統事先為任何特定司機預測最佳路由的能力受到交通擁堵的不穩定特性的阻礙。
當諸如netflix之類的單個公司佔網際網路高峰流量的三分之一以上時，同時通過網際網路提供數字信息(特別是大量線性數據)的公司必須以某種方式解決網際網路擁塞的日益不穩定的特性。類似地，隨著移動語音和數據使用的快速增加，受監管的rf頻譜的有限可用性尤其受到開發高帶寬移動應用的公司關注。
雖然本文中在通過網際網路向大量並發用戶傳送流傳輸視頻的上下文中描述本發明的特定應用，但是本發明的原理同樣適用於網絡組件之間的共享鏈路的有限容量約束了對可被轉換為數字格式的任何類型的信息(例如，音頻、圖像、3d模型等)的路由的眾多其他上下文。本發明的其它潛在應用包括例如voip、公司視頻會議、虛擬實境、多玩家遊戲以及各種其他帶寬密集型應用(在任何給定時間點相對於底層網絡內的共享鏈路的擁塞級別而言)。
如下面將更詳細地討論的那樣，本發明並不「治癒」諸如網際網路之類的底層網絡內的組成鏈路處的有限容量或「網絡擁塞」的問題，而是通過以下方式來有效地利用該有限容量：監視並分析那些鏈路上的網絡流量，以優化數字內容在基於對那些鏈路上的擁塞級別的預報來動態重新配置的覆蓋網絡的節點之間的路由。
視頻流傳輸事件
由於網際網路和基於ip的路由的出現，出現了許多通過網際網路流傳輸視頻的方法。在討論其相對優點和缺點之前，回顧並考慮正在解決的問題是有幫助的。要通過網際網路分發視頻內容，必須先對視頻內容進行捕獲和數位化。我們可以將視頻內容描述為「實況地」捕獲到(或數字地生成)並通過網際網路分發的「事件」。本文中提及視頻事件包括視頻和音頻二者以及關聯的任何元數據的捕獲或生成。
視頻事件可以是調度的或非調度的。例如，「超級碗(superbowl)」是一個調度事件，因為它發生的時間是事先知道的，而其他事件(例如，自然災害、幼兒的第一步、甚至視頻點播「vod」)是非調度的，因為它們可能在很少或沒有提前警告的情況下發生。
視頻內容可以在隨著傳遞任何其他類型的文件(例如，經由「ftp」或文件傳輸協議)一起通過網際網路分發之前被全部捕獲以生成數位化視頻文件。然而，這種「文件傳遞」方法對接收者觀看(播放)視頻內容造成延遲，即，接收者必須等到整個文件已被傳遞才能觀看視頻內容。假設是文件大小相對較大的數位化視頻，這種延遲可能很大。
因此，視頻內容經常被「流傳輸」給用戶，使得在內容仍然被發送的同時用戶就可連續地接收和觀看該內容。實質上，視頻內容被分為多個小文件或「視頻段」(例如，長度為1到10秒)構成的有序線性流，所述小文件或「視頻段」被傳送給用戶，用戶可以在接收它們時開始觀看它們。為了觀看無延遲或無抖動的視頻內容的連續流，每個視頻段必須以規律的間隔播放，例如每秒30幀(fps)。但是，要注意，視頻段並不需要以規律的間隔接收，只要每個段在先前段的播放結束之前收到即可。
無論事件是調度的還是非調度的，它都可被「實況」(即，在事件發生時)流傳輸或被「預先錄製」供在事件發生之後的任何時間流傳輸。例如，超級碗可以在事件發生時被捕獲並流傳輸，或者被預先錄製供在以後的時間流傳輸。
最後，無論事件是調度的還是非調度的，以及無論其是預先錄製的還是在事件發生時實況流傳輸的，都可以「實時」地流傳輸(即，從發送者到接收者的延遲在很大程度上感覺不到)或者在傳輸中「延遲」幾秒甚至幾分鐘。例如，通過網際網路但不是實時流傳輸的電視節目(例如，棒球比賽)的觀眾可能在彼此不同的時間上體驗該流傳輸的事件，或與觀看通過線纜或衛星廣播的同一節目的觀眾在不同時間上體驗該流傳輸的事件。這種延遲(特別是如果超過幾秒鐘)可能會降低用戶的「體驗質量」(qoe)，即以用戶為中心的或應用級視角的質量，這與「服務質量」(qos)形成對比，服務質量是基於以網絡為中心的度量(例如，分組延遲、分組丟失或由路由器或其他網絡資源引起的抖動)的性能測量。
例如，由於觀眾在不同時間經歷相同事件這一事實，觀眾之間的社交互動可能受到限制(完全不同於抖動或其他視頻偽像)。當通過許多不同的方式(從廣播電臺或電視到社交媒體和其他網際網路服務，經由手機、臺式機和膝上型計算機可訪問的方式，以及經由消費電子設備的不斷發展的領域的方式)實時傳達許多事件(調度的或非調度的)的今天，這特別會成為問題。
因此，期望視頻流傳輸系統處理非調度事件和調度事件，流傳輸實況的和預選錄製的事件，以及以最小延遲實時流傳輸這些事件，以便為觀眾提供一致的qoe。而且，隨著流傳輸視頻事件的並發觀眾的數量增加，保持一致的qoe成為一個棘手的問題。為此，可擴展性是任何此類系統的關鍵設計目標。
儘管最近在視頻流傳輸技術方面取得了進步，但是網際網路基礎設施的歷史性的「adhoc」演進仍然對基於網際網路的視頻流傳輸造成了重大的障礙，不僅僅在於其不一致的qos，這還導致網絡擁塞在時間上和在網際網路上的位置很難預測。雖然本發明的一個關鍵目標是為流傳輸視頻事件的觀眾保持一致的qoe，但是該目標受到網際網路上基本上不能消除的網絡擁塞的限制。
底層網際網路架構
從arpanet(用於實現網際網路協議組或tcp/ip的最早的分組交換網絡)開始，以及隨後的nsfnet，網際網路「骨幹(backbone)」被設計為冗餘的「網絡之網」(即網際網路)，其通過分散控制和為信息提供備選通信(路由)路徑以達到其期望目的地來提供可靠性或「彈性」。然而，對於在路由器和其他共享網絡資源之間遵循不同路徑的分組，在網際網路上維持一致的qos或qoe仍然是一個非常困難的問題。
隨著網際網路骨幹的演進和私有化，傳統骨幹網絡與長途電話運營商擁有的骨幹網絡之間的冗餘和重疊也發展了。出於本說明書的目的，我們區分大型「公共」網絡和大型「私有」骨幹網絡，大型「公共」網絡直接向用戶提供數據或者通過其他較小的「網際網路服務提供商」(isp)網絡向用戶提供數據，大型「私有」骨幹網絡僅在它們自身之間攜帶數據或者用作大型isp之間的渠道，但不直接向客戶提供數據。在這兩種情況中的任一情況下，這些大型公共網絡和大型私有網絡通常被實現為通過光纖幹線(即多條光纖線纜捆綁在一起以增加網絡容量)互連的「光纖環」。
出於路由目的，攜帶最大網絡流量的最大網絡提供商(例如，大型isp和私有骨幹網絡)被分配稱為「自主系統」(as)的ip路由前綴塊，其中每個ip路由前綴塊被分配「自主系統號」(asn)。我們通過asn來指代這些公司擁有的每個大型光纖環。asn的數量近年來急劇增長，從15年前的大約5000個asn到今天全球超過50,000個asn。如上所述，許多大型網絡提供商也擁有不為客戶提供服務但可以連接到他們自己的「公共asn」或其他人所擁有的asn的骨幹光纖環網(即私有asn)。
由於不同的公司擁有自己的asn，它們彼此籤訂協議，以促進跨越asn的和遍及全球網際網路的網際網路流量的路由。每個asn採用稱為「邊界網關協議」或bgp的路由協議，使用通常稱為「對等點(peeringpoint)」的一組路由器來控制對另一asn的訪問。任何給定的asn可以使用多個對等點來連接到多個不同的asn。互連的asn可以是地理上相鄰的，或者可以相距很遠，經由跨越很遠距離的長光纖幹線連接的(例如，跨國家甚至跨海洋)。公共asn也可以經由「私有asn」或骨幹網絡互連。
監視asn內部的和asn之間的qos是非常困難的。大型網絡提供商將自己的asn內的大部分路由和性能信息(包括動態擁塞度量)保留為專有的。雖然(目前的bpg版本4的)「開放消息格式」在建立到bgp路由器的tcp/ip連接時提供了某些信息的「數據轉儲」，但這種機制在實際中並不是非常有用。許多bgp路由器不支持開放消息格式，而其他路由器則簡單地將其關閉。此外，該信息通常是5分鐘過時，考慮到網際網路上擁塞級別變化的頻繁程度，這是相對較長的時間。
由於這麼大量的網際網路流量流經用於互聯asn的相對高帶寬的對等點，所以這些對等點通常是關鍵「瓶頸」或者是在任何給定時間在網際網路上的大部分擁塞的來源，這不同於asn內的「最後一公裡」問題(即，最終用戶與其「網關」isp之間相對較低帶寬的有線和無線連接上的擁塞)。
例如，隨著跨asn對等點的流量負載增加，對等點每側的asn中的路由器變得擁塞。換言之，這些路由器經歷著對ram、cpu和其他容量有限的共享資源的高利用率。對這些資源的增長的需求降低了這些對等點上的性能(例如，比特速率)，並且最終可能導致丟失數據分組。由於網際網路上的網絡流量不是集中控制的，所以很難預測在任何給定的時間網際網路上的頻繁變化的「對等點擁塞」級別。
如果不能保證在asn內和asn之間保持一致的qos，那麼為流傳輸視頻事件的觀眾保持一致的qoe變得非常困難。通過網際網路流傳輸視頻的任何系統都受到共享路由器的不可靠性和不斷變化的擁塞級別的影響，特別是在流過非常多網際網路流量的asn對等點處更是如此。當將視頻通過網際網路(特別是跨這些asn對等點)流傳輸給大量並發觀眾時，這個問題更加嚴重。
現有的視頻流傳輸方案
在過去幾十年中，通過網際網路流傳輸視頻的各種方案已經得到演進，其中，大量術語被利用來表徵和區分用於生成(在網際網路之上的)覆蓋網絡拓撲並在沿著這些覆蓋網絡的網絡節點之間傳送視頻內容的不同技術。在比較不同的方案時，簡單地回顧gps導航模擬並考慮影響在任何兩個點或節點之間行進所需時間的因素，即距離、速度和擁塞(通常通過沿不同路徑重新路由來解決)，這是有幫助的。
在網際網路上路由分組的上下文中，距離(或地理鄰近度)不是直接相關的，因為分組的行進接近光速。然而，速度受到沿著路由遇到的停靠點或路障的數量的影響，或者在這種上下文下，受到在兩個節點之間的中間路由器處遇到的「跳(hop)」的數量的影響。因此，如果兩個節點只隔著相對較少的跳數，則可以將其稱為彼此「接近」(在「網絡鄰域」中)，而不管它們的地理鄰近度如何。沿著兩個節點之間的路徑的中間節點處的擁塞會影響總體行進時間，並且可以通過動態地重新路由流量(即，動態地重新配置確定兩個節點之間的路徑的覆蓋網絡)來解決。如下面將要討論的，這些因素用於闡明在網際網路上流傳輸視頻的不同方案之間的關鍵區別。
在網際網路之外傳送視頻的最常見的方法是將視頻流(例如，電視節目)從「起點(pointoforigin)」同時廣播給所有目的地觀眾，例如經由專用線纜或衛星基礎設施來廣播。雖然網絡集線器可能被用在lan中向所有網絡節點廣播信息，但在網際網路上跨交換機和路由器廣播視頻段的分組將會是非常不切實際和低效的。大多數網絡用戶不會對觀看視頻內容的任何給定的「頻道」感興趣，並且由於向其他路由器廣播視頻段的路由器將被迅速壓垮，在起點附近將會出現明顯的擁塞。對於通過網際網路將視頻內容頻道從單個起點傳送給可能隨時加入頻道的大量並發觀眾而言，廣播解決方案是不可行的。
備選的「多播」方案涉及將每個視頻段從起點同時流傳輸給網際網路上的預定義的節點組。這種方法對於通過網際網路進行大規模視頻分發同樣不切實際。此外，需要專門的基礎設施，例如具有多播功能的專用路由器，這對於大規模商業使用也是不切實際且昂貴的。
與廣播和多播技術相比，視頻流傳輸的「單播」方案涉及將視頻段從起點發送給單個目的地節點(例如，通過與所定義的目的地節點ip地址建立tcp/ip連接)。但是，向每個觀看節點同時傳送大量單播分組也將會迅速壓垮起點處或起點附近的路由器，並且由於上述許多原因而無法實現一致的qos，更不用說提供足夠以處理這樣大量的同時傳輸的帶寬所需的巨大成本。
一些vod公司(如netflix和youtube)採用了這種單播方案的變體，其通常依賴於昂貴的「邊緣伺服器」基礎設施。這種方案(有時稱為「內容傳送網絡」或cdn)涉及在網際網路上部署多個物理伺服器，並將每個視頻內容頻道的副本分發給每個伺服器。因此，觀看節點可以從附近(在網絡鄰域內，即與觀看節點僅相距相對較少的跳)的伺服器接收所需的視頻內容。
每個邊緣伺服器通常具有相當大的帶寬和計算能力，並且基本上構成單獨的視頻內容源，附近的觀看節點可以在任何時間點從該視頻內容源(「按需」)獲得任何視頻內容頻道。這種添加物理基礎設施的方案有點類似於建造附加的高速公路和出口，以使更多的人能夠更快地(較少的轉彎和更少的時間花在較慢的道路上)到達熱門目的地。
雖然不同的用戶通常希望在任何給定時間觀看不同的視頻頻道，但是vod系統偶爾會面臨「高峰」需求時段，在此期間，特定的視頻事件必須被流傳輸給大量的並發觀眾(例如，流行電視劇的最後一集)，這甚至可能壓垮最大的流傳輸視頻公司的基礎設施，或者至少導致昂貴的基礎設施的低效「最壞情況」部署，其中昂貴的基礎設施經常未被充分使用(即在非高峰需求的更常見的時間段)。備選的vod解決方案已經嘗試通過在網絡節點本身之間複製和分發視頻內容來避免對昂貴的邊緣伺服器基礎設施的需求(例如，在美國專利公開no.2008/0059631中所討論的)。
無論是否使用昂貴的邊緣伺服器基礎設施，這些vod解決方案都不能解決非調度視頻事件的qos問題，因為它們都依賴於「預播種(pre-seeding)」邊緣伺服器或者整個網際網路上的觀看節點預先知道內容，以確保附近的視頻內容來源。流傳輸實況的非調度事件將需要將視頻內容實時並發傳送給所有這些邊緣伺服器或觀看節點，這是這些vod系統中任何一個都沒能解決的問題。
最近，某些基於單播的視頻流傳輸標準(例如，「webrtc」)已得到演進，以促進臺式機網絡瀏覽器和行動網路瀏覽器之間視頻的「點對點」流傳輸，而不需要任何插件。許多現有的智慧型手機以及臺式計算機和筆記本計算機都包括webrtc庫和「自適應流傳輸」庫，其中webrtc庫支持瀏覽器到瀏覽器視頻流傳輸，以及「自適應流傳輸」庫使觀看節點能夠實時檢測其帶寬和cpu容量，並自動請求較低或較高的「比特速率」來適配這些度量的改變。
自適應流傳輸實現包括蘋果的「http實時流傳輸」(hls)、微軟的「平滑流傳輸」和「mpeg-dash」iso標準等。在典型的點到點視頻流傳輸場景中，接收節點周期性地向http伺服器請求「清單文件」，所述清單文件包括即將到來的(例如，接下來的八個)視頻段的每個可用比特速率版本所在的位置。例如，每個視頻段可能存在1080p、720p和480p版本可用，不同版本反映出不同的「視頻解析度」，不同的視頻解析度需要不同的流傳輸比特速率(帶寬)，以確保每個視頻段不管其解析度如何都在基本上相同的時間量內傳送。
標準的html5視頻播放器(在支持webrtc的網絡瀏覽器中)通常會在其開始播放視頻內容之前緩衝三個視頻段。它們使用當前的清單文件向http伺服器發送針對每個視頻段的http請求。發送節點然後根據webrtc標準將每個視頻段(以小「塊」的形式)推送給接收節點供在接收節點的網絡瀏覽器中回放。如果接收節點支持自適應流傳輸實現，並且確定接收最近的視頻段所需的時間顯著增加或減少，則它自動開始從清單文件中的選擇中請求較低或較高比特速率的視頻段。換言之，它通過改變其請求的視頻段的解析度來隨時間「適配」其實際帶寬。
視頻幀的「解析度」是幀的寬度x高度(例如，1920×1080或1080p)或一幀中的像素數量這樣的度量，而其「比特速率」指代從發送方向接收方發送的「每秒比特」數(bps)。例如，如果每秒傳輸30幀1080p解析度的視頻(每秒30幀或30fps)，並且每個顏色像素包含24比特(每像素24比特或24bpp)，則比特速率將等於接近1.5tbps(1,492,992,000bps，即1,492,992,000＝(每幀1920x1080像素或1920x1080ppf)x(24bpp)x(30fps)。
標準視頻編解碼器採用壓縮(例如，mpeg2壓縮)和其他視頻編碼技術來產生較低的有效比特速率(例如，3mbps)。鑑於上述情況，「比特速率」和「解析度」是高度相關的，因為可以通過提供更高或更低解析度的視頻幀來增加或減少有效比特速率。因此，在這點上，我們某種程度上可互換地使用這些術語。
webrtc和自適應流傳輸標準允許幾乎任何智慧型手機用戶捕獲和流傳輸實況視頻事件，並且還使得這樣的用戶能夠加入源自網際網路上的另一起點(範圍從其他個人智慧型手機用戶到擁有大量視頻內容的大型公司)的流傳輸視頻頻道。然而，這些標準被設計用於點對點視頻流，並且不解決向網際網路上的大量並發觀眾流傳輸視頻頻道的「視頻傳送」問題。
為了解決這個問題，一些視頻流傳輸公司(例如，streamroot)採用了一種通常涉及「點對點」(p2p)或網格網絡拓撲的方案，其中視頻內容從一個觀看節點轉發到另一觀看節點(有時稱為「peercasting」)。在視頻流傳輸的上下文中，這些術語可以互換地用於指代配置在網際網路之上的覆蓋網絡，其使得觀看節點能夠以分布式方式彼此中繼流傳輸視頻內容。然而，應該區分向大量並發觀眾進行的流傳輸視頻傳送與p2p或網格網絡拓撲的非流傳輸使用(其例如用於文件傳遞或文件共享應用的)。
p2p視頻流傳輸系統將來自單個起點的視頻內容頻道傳送給網際網路上的大量並發用戶。這樣的系統往往趨向於是彈性的和可擴展的，因為它們的分布式特性有助於從個別故障點恢復(例如，通過經由其他節點重新路由內容)，並且隨著越來越多的節點被添加到網絡，其可靠性和性能實際上得到改善(即，因為更多更好的路由「中繼」選項變得可用)。
當新節點加入視頻頻道或現有節點離開(停止觀看)該頻道時，p2p視頻流傳輸系統必須在某種程度上動態地重新配置覆蓋網絡的拓撲，即修改網絡節點中的至少一些路由路徑以適應新的節點。例如，當添加新節點時，在選擇新節點將從其接收(和將向其中繼)視頻內容的附近的現有節點的努力中可以考慮新節點的地理位置。
但是，如果僅基於其地理鄰近度來選擇「對等」節點，則它們仍然可能彼此相對「遠離」(而不是位於網絡鄰域內)——例如，如果它們駐留在不同的asn中的話。因此，它們之間的流量可能跨越一個或多個潛在擁塞的對等點。例如，在接近的地理鄰域中的兩個節點之間的實際等待時間可能會超過那些節點中的每一個與在地理上遙遠的節點之間的延遲之和。這種現象有時被稱為「三角不等式違例」(triangleinequalityviolation，簡稱tiv)，其示出了依靠bgp路由在跨asn對等點的覆蓋網絡的節點之間傳送數字內容的缺點。
現有p2p視頻流傳輸系統的這個問題的一個原因是它們未被構造為與網際網路的底層架構「兼容」。建立在網際網路之上的任何覆蓋網絡拓撲仍然受到許多中斷或故障點(不同於新節點或消失的節點)的影響，如上面提到的眾多qos問題。因為沒有解決網際網路的底層qos波動(特別是在asn對等點處的qos波動)，這樣的系統在向其用戶提供一致的qoe方面面臨重大障礙。
因此，現有的p2p視頻流傳輸系統(如gps導航系統)依靠地理鄰近度(而不是網絡鄰近度)來選擇對等中繼節點，並且一旦遇到擁塞，僅在「事後」重新路由流量。此外，線性數據到並發用戶的實時流傳輸施加了在gps導航系統中沒有發現的額外約束——內容必須「同時」到達每個節點處。邊緣伺服器和其他物理基礎設施方案(類似於建設高速公路和出口以提供更高速的路由)是昂貴的，並且也無法充分解決非調度事件和任何特定事件的高並發使用的問題。
因此，需要一種解決上述缺陷的數字內容傳送系統，並且在生成和動態重新配置覆蓋網絡時考慮網際網路的底層架構(特別是流過如此多的網際網路流量的asn對等點處)，以便為客戶端節點提供一致的qoe。
技術實現要素：
根據本發明，關於數字內容傳送系統公開了新穎的方法和架構的各種實施例，該數字內容傳送系統通過以下方式向底層網絡(例如，網際網路)上的節點的用戶提供一致的qoe：(1)維護將底層網絡的組件(例如，asn和將其互連的對等點)互聯的共享鏈路的地圖，包括組件之一內(例如，在asn內)的每個節點的位置；(2)通過監視沿著建立在底層網絡(網際網路)之上的一個或多個覆蓋網絡的使那些共享鏈路(asn對等點)交叉的節點之間的網絡流量來生成度量；(3)隨時間分析所述度量和所述地圖，以預報反映共享鏈路(asn對等點)隨時間改變的容量的擁塞級別；以及(4)基於所預報的擁塞級別動態地重新配置覆蓋網絡的拓撲，以生成數字內容在沿覆蓋網絡的客戶端節點之間的最佳路由。
本文中在一個或多個視頻內容頻道的觀看者之間提供一致的qoe的上下文中描述了本發明的「虛擬廣播」系統的具體實施例，在所述上下文中每個頻道都從單個起點向潛在大量並發觀眾(其可在不同時間加入該頻道)進行實時流傳輸(同時避免對邊緣伺服器或其他昂貴的物理基礎設施的需求)。如下面將更詳細地解釋的，我們在向並發用戶進行線性內容的單播流傳輸的上下文中使用術語「虛擬廣播」。儘管使用單播流傳輸來路由內容，但是從用戶的觀點來看，內容是「廣播」給他們的，因為它們同時接收內容。在許多其他上下文中，本發明的其他實施例對於本領域技術人員將是明顯的，在所述許多其他上下文中，網絡組件之間的共享鏈路的有限容量限制了對可被轉換為數字格式的任何類型的信息的路由。
出於本說明書的目的，並發地接收多個不同頻道的單個節點可被認為是不同的覆蓋網絡上的不同節點，每個節點由單個頻道定義。在vod上下文中，對特定節目的每個單獨的「放映」可被認為是具有其自己的觀看節點網絡的單獨頻道。
本發明的系統能夠處理未調度的事件和調度的事件，流傳輸實況事件和預先錄製的事件，並且通過高度可伸縮的方式以最小的延遲實時流傳輸那些事件，其在大量的並發用戶之間保持了一致的qoe，儘管是在建立在網際網路上的受到網際網路的qos波動影響的覆蓋網絡上實現的。系統的性能和用戶的qoe實際上會隨著並發用戶的數量(特別是在任何給定的asn內)的增加而提高。
採用客戶端-伺服器架構來集中伺服器端路由決策。通過動態可重新配置的p2p覆蓋網絡實現視頻內容的分布式流傳輸，所述動態可重新配置的p2p覆蓋網絡支持視頻內容在每個視頻頻道的觀看節點之間被中繼(即「推送」給觀看節點)。客戶端節點可能會使用標準的html5視頻播放器(內置於大多數臺式機網絡瀏覽器和行動網路瀏覽器中)來查看或播放視頻，並依靠自定義的嵌入式代碼(如javascript)來實現附加功能，例如管理視頻段的接收，將那些視頻段中繼給其他節點，以及監視各種性能度量。在其他實施例中，這些功能中的一些或全部可以集成到定製應用或移動app中。
本發明的系統有助於臺式機網絡瀏覽器和行動網路瀏覽器之間的「點到點」視頻流傳輸，並通過自動請求更低或更高比特速率的視頻段來適配節點帶寬的變化。在一個實施例中，虛擬廣播系統採用單播標準(包括webrtc和自適應流傳輸標準(例如hls、mpeg-dash或平滑流傳輸)以促進視頻流傳輸，而不需要網絡瀏覽器插件，並且使得節點能夠檢測它們的性能能力，如帶寬和cpu容量。
將每個事件提供給中央「虛擬廣播伺服器」，以便「起點」通過多個動態可重新配置的覆蓋網絡將每個頻道傳送給並發用戶。事件可以從幾乎任何來源(包括cdn)獲得，無論是作為完整文件傳遞還是實況流傳輸給虛擬廣播伺服器。在使用webrtc的實施例中，具有實現webrtc的智慧型手機的任何用戶可以上載預先錄製的視頻事件，或者實況捕獲事件並將其上載到虛擬廣播伺服器(以及查看從虛擬廣播伺服器流傳輸的其他頻道)以供後續經由覆蓋網絡向用戶傳送。
在一個實施例中，虛擬廣播伺服器包括「poi內容伺服器」，該「poi內容伺服器」擔當每個頻道的起點，從該起點經由構建在網際網路之上的的動態可重新配置的覆蓋網絡傳送視頻段。視頻段通常是大小固定的(例如，從1到10秒)，該大小由視頻事件的始發發行者確定。視頻段被客戶端節點觀看，並沿著通過覆蓋網絡定義的路由逐節點地「推送」(即，根據webrtc標準，作為各個固定大小的「塊」來中繼)。在一個實施例中，當通過mpeg2傳輸協議流傳輸時，每個視頻段被劃分成64kb塊以匹配udp數據報「分組」的大小，以獲得最大的效率。
雖然在大多數情況下視頻段被有效推送到每個客戶端節點，但是在一個實施例中，客戶端節點可能檢測到視頻段的所有塊都沒有及時到達，並且可以利用當前清單文件來向poi內容伺服器(即，作為「回退」饋送位置)請求該視頻段。
當每個節點尋求加入通過poi內容伺服器可獲得的頻道時，該節點確定(在另一個實施例中，在虛擬廣播伺服器的協助下)該節點所駐留在的特定asn。虛擬廣播伺服器利用該「asn位置」信息，連同網際網路的動態「asn互連地圖」(包括asn及其各種對等點互連)以及各種監視到的性能度量，來優化頻道內容在覆蓋網絡之間的路由，所述覆蓋網絡是基於對這些asn對等點處的擁塞級別的預報來動態重新配置的。在另一個實施例中，除了每個節點的asn位置之外，虛擬廣播伺服器還利用其地理位置來協助該過程。
在一個實施例中，覆蓋網絡的拓撲定義了視頻段在觀看節點之間的路由路徑，並且針對頻道的每個視頻段是可動態(整體或部分)重新配置的。在另一個實施例中，它們被針對視頻段的每個塊來動態地(整體或部分地)重新配置。以這種方式，在確定視頻頻道的每個視頻段的最佳路由路徑時，考慮網際網路的架構(以及asn對等點處的預報的擁塞級別)。在另一個實施例中，如果沿著覆蓋網絡的一些或所有路由能夠及時地傳送視頻段(即使這樣的路由是非最優的)，則不重新配置這樣的路由，直到滿足預定義的擁塞閾值為止，或者直到識別出另一足夠嚴重的問題時才會重新配置路由。
在一個實施例中，客戶端節點監視與例如網際網路上的最後一英裡問題和qos問題(包括asn對等點處的擁塞)以及由虛擬廣播系統自身的一個或多個頻道的並發觀眾的數量引起的擁塞相關的性能問題。它們監視聯繫網際網路上的和跨asn的指定站點所需的時間，以及將視頻段中繼到其他節點所需的時間。將客戶端監視到的度量傳遞給虛擬廣播伺服器，以用於進行動態路由決策。在一個實施例中，虛擬廣播伺服器包括通過標準網絡套接字(websocket)協議與客戶端節點通信的「信令伺服器」。
客戶端節點可選地包括「上載器」，所述上載器使用戶能夠捕獲視頻事件並將其實時上載到虛擬廣播伺服器。因為從任何客戶端節點到虛擬廣播伺服器的路徑可能跨多個asn，所以使用自定義「淋浴(showering)」協議來促進視頻事件的流傳輸，並避免分組在中間路由器處被延遲或阻塞。在一個實施例中，客戶端節點還可以通過虛擬廣播伺服器上的「潑濺提取器(splashextractor)」搜尋引擎來搜索並查看「趨勢」事件(這裡稱為「潑濺(splash)」)，所述搜尋引擎識別潑濺，並且基於用戶搜索向用戶提供能夠流傳輸和查看來自網際網路上的趨勢事件的能力，該能力通過poi內容伺服器原本是不可用的。
在節點請求加入頻道時，虛擬廣播伺服器基於節點的中繼能力(即其可靠的「上遊」帶寬)對節點進行分類，該中繼能力是根據各種因素推導出的，所述因素包括其連接類型(例如，3g或4g蜂窩、wifi、lan等)以及其cpu、作業系統、瀏覽器和內存配置，以及隨時間監視到的其他固定的和可變的性能指標。在一個實施例中，根據節點的相對中繼能力將節點分為三個級別。最低級別節點(「c」節點)可以查看視頻段，但不能將視頻段中繼給其他節點。中間級別節點(「b」節點)可以查看視頻段並在asn內中繼視頻段。最高級別節點(「a」節點)可以查看視頻段並將視頻段中繼給asn內部的和跨越asn的其他a節點。
在另一實施例中，可以例如基於監視到的性能度量以及系統對於給定分類的更多或更少的中繼節點的當前需求來動態地改變節點分類。另外，如果在asn內存在足夠多的a節點來中繼視頻段，則可以將a節點指定為「b∶a」節點，指示它將被視為b節點，但是如果需要(例如，如果現有的a節點離開了頻道)，則可以升級為a節點。在一個實施例中，如果單個節點在性能上表現出顯著的改變(更好或更差)，則可以對該節點重新分類(例如，從b節點到c節點，反之亦然)，以及如果問題自身得到解決，則恢復到該節點的初始分類。
在另一實施例中，客戶端節點被分配多個「時隙」(例如，基於其能力和客戶端性能度量)，以使得它們能夠向多個其他節點中繼視頻段的塊以及從多個其他節點接收視頻段的塊。在該實施例中，客戶端節點僅從一個「饋送」節點接收視頻段，但是可以將該視頻段「饋送」或中繼給多個其他客戶端節點。最多向a節點分配8個中繼時隙，其中4個用於中繼至同一asn內的a個節點，4個節點用於中繼到其他asn中的a個節點，即跨越asn對等點。最多向b∶a和b節點分配8個時隙，用於中繼到其asn內的其他客戶端節點(即其他b∶a、b和c節點)。在另一實施例中，客戶端節點可以由多個其他客戶端節點(例如，通過將塊在多個輸入時隙之間交替)進行「饋送」。該技術可以用於需要更高性能的高比特速率(例如，4k)視頻流。
在另一實施例中，某些節點(例如，基於其能力和客戶端性能度量)可以從單個饋點節點接收視頻段的多個解析度(或在備選實施例中，從不同饋點節點接收不同解析度)。如果這些節點的上遊帶寬足夠，則它們可以被認為是「聚播(polycast)」節點，並且在所需的程度上還可以將視頻段的這多個解析度版本中繼或饋送給一個或多個指定節點。
為了促進覆蓋網絡的動態重新配置，虛擬廣播伺服器採用「深度映射器」深度學習引擎，所述「深度映射器」深度學習引擎連續分析性能度量以預測跨asn對等點的擁塞級別，即預測將來短時間(例如，1分鐘)內asn對等點的擁塞級別。在一個實施例中，針對a節點之間的每個潛在的asn間路徑(例如，從一個asn中的一個a節點到另一個asn中的a節點)生成預測的「擁塞值」。在另一實施例中，擁塞值反映了每對a個節點之間的最佳路徑的預測的擁塞級別。
在一個實施例中，虛擬廣播伺服器使用「覆蓋網絡創建器」來生成並(全部或部分地)重新配置asn間覆蓋網絡和asn內覆蓋網絡，例如確定用於將視頻段在asn內和跨asn地從一個節點向另一個節點推送的最佳路徑。在該實施例中，覆蓋網絡創建器考慮每個節點可以利用的可用時隙的數量以及每個節點可以接收或中繼的解析度的數量。
覆蓋網絡創建器生成並動態地重新配置(在深度映射器的幫助下)跨asn的「虛擬數據幹線」覆蓋網絡，其表示a節點的拓撲。換言之，它表示a節點以及視頻段將遵循的在asn內的和(特別地)跨asn的那些a節點之間(即通過潛在的擁塞asn對等點)的鏈路或路由路徑。
虛擬數據幹線識別將被指示從附近的poi內容伺服器(例如，使用當前清單文件)請求每個視頻段的a節點的集合以及每一個都將推送該視頻段的a節點的集合等等(在asn內和跨asn)。因此，該視頻段將分布在包含觀看節點的每個asn上。為了到達每個觀看節點，該段也可能行進通過沒有觀看節點的臨時專用骨幹asn。
覆蓋網絡創建器還生成一個或多個asn內「群組(swarm)」覆蓋網絡，以將視頻段從asn內的a節點中繼到該asn內的b∶a、b和c節點。可以針對每個視頻段(或者在備選實施例中，針對視頻段的每個塊)來(整體或部分)動態地重新配置這些群組覆蓋網絡。在一個實施例中，asn內的每個群組覆蓋網絡表示b∶a節點、b節點和c節點的分層拓撲(相對於asn內的a節點而言)，該b∶a節點、b節點和c節點在該群組分層體系中的節點之間接收、觀看和中繼(除c節點外)視頻段。
因此，本發明的虛擬廣播系統和方法通過監視和分析網絡流量以優化數字內容在虛擬數據幹線覆蓋網絡和群組覆蓋網絡的節點之間的路由，有效地利用asn對等點和其他擁塞關鍵點的有限容量，其中該虛擬數據幹線覆蓋網絡和群組覆蓋網絡是基於對這些擁塞關鍵點處的擁塞級別的預報來動態重新配置的，從而在系統用戶之間保持一致的qoe。
附圖說明
圖1是示出在網際網路之上動態配置的本發明的覆蓋網絡的一個實施例的圖；
圖2是示出本發明的客戶端流傳輸視頻設備的關鍵的客戶端側組件的一個實施例的框圖；
圖3是示出本發明的虛擬廣播伺服器的關鍵的伺服器側組件的一個實施例的框圖。
圖4是示出本發明的動態視頻流傳輸過程的一個實施例的流程圖。
具體實施方式
在附圖中示出並在下面描述本發明的系統和方法的詳細實施例。首先應當注意，本發明不限於下面參照附圖討論的具體實施例。
如上所述，雖然在本文中在通過網際網路向大量並發用戶傳送流傳輸視頻的上下文中描述本發明的特定應用，但是本發明的原理同樣適用於許多其他上下文中，在這些其他上下文中，網絡組件之間的共享鏈路的有限容量約束了對任何類型的數字內容的路由。
即使在通過網際網路傳送流傳輸視頻的上下文中，本文描述的客戶端節點和伺服器組件之間的功能分配也是設計折中的結果，並且大部分功能可以在客戶端側組件和伺服器側組件之間重新分配，而不會背離本發明的精神。類似地，客戶端側功能可以被分配到單個模塊化組件中或分散在多個不同的組件中，並且可以被實現為一個或多個獨立的應用或移動app，或者實現為獨立應用或app和javascript或其他腳本或程式語言的組合。此外，伺服器側組件可以在單個硬體伺服器上實現或跨多個不同的伺服器實現。這樣的功能也可以被集成到單個軟體模塊中，或者被分配在跨一個或多個硬體伺服器分布的不同軟體模塊之間。
最後，在使用標準協議和庫(例如，http、網絡套接字、webrtc、stun和各種自適應流傳輸標準)的那些實施例中，由這些標準協議和庫中的一些或全部提供的功能可以用其他標準或專有實現來替換，而不背離本發明的精神。
覆蓋網絡
圖1是示出映射在網際網路之上的本發明的覆蓋網絡100的一個實施例的圖。儘管網際網路本身可以以各種不同的方式進行示出，但是圖1示出了作為經由對等點120互連的asn110光纖環的集合的網際網路。在每個asn110內示出了在任何時間點觀看特定視頻頻道的各個客戶端節點。雖然在圖1中未示出，但是多個頻道可以並發地激活以及因此多個覆蓋網絡集合100(在一個實施例中)可以並發地激活。
如上所述，虛擬數據幹線覆蓋網絡表示asn110內的a節點130之間的互連175(直接連接)和跨asn110的a節點130之間的互連175(即，經由對等點120)二者。骨幹連接器195示出了經由私有asn(未示出)的兩個asn110之間的a節點的互連，其中所述私有asn不包括任何商業節點而僅互連兩個公共asn110。例如，骨幹連接器195被示出為連接asn110-f中的a節點130與asn110-e中的a節點130。在這種場景下，那兩個a節點130之間的流量可行進通過多個「私有」對等點120(或與私有asn的其他專有連接)。
如上所述，在一個實施例中，這樣的連接的性能可以僅在端點(即，兩個a節點130)處監視，如兩個不同的公共asn110中的a個節點130之間的連接175(即，經由對等點120)的情況。沿相同asn110中的兩個a節點130之間的連接175的流量可能會比跨asn110的流量相對更快，因為它不會穿過可能擁塞的對等點120。雖然使用單向箭頭示出了背景連接器195以及來自/去往a節點130的連接175，但是這些僅反映當前的單向路由路徑，儘管在圖1所示的所有客戶端節點之間都支持雙向連接。
應當注意，本發明的任何兩個客戶端節點之間的所有流量穿過公共網際網路，並且因此通過影響qos的各種中間路由器(未示出)。系統監視asn110內的和跨asn110(以及因此跨一個或多個對等點120)的qos影響。在一個實施例中，這樣的asn內流量和asn間流量由每個客戶端節點(在虛擬廣播伺服器的方向)進行監視，並被傳送給虛擬廣播伺服器，以用於動態重新配置由覆蓋網絡100(包括a節點130之間的虛擬數據幹線覆蓋網絡和從asn110內的每個a節點130到該asn110內的b(以及b∶a)節點140和c節點150的群組覆蓋網絡)表示的節點和路由路徑。
圖1示出了在這些覆蓋網絡100的「當前狀態」的情況下視頻段在客戶端節點之間所遵循的各種路由路徑。換言之，它示出了這些覆蓋網絡100的當前拓撲，在一個實施例中，可以針對每個視頻段(並且在備選實施例中，針對視頻段的每個塊)動態地重新配置這些覆蓋網絡100。應當注意的是，對於任何特定的視頻段，覆蓋網絡100可以(整體或部分地)重新配置也可以不(整體或部分地)重新配置，因為該決定將至少部分取決於隨時間收集的性能度量。
asn110-c示出了這樣的場景，其中poi內容伺服器(未示出)駐留在asn110-c中或附近(例如，跨一個或兩個其他asn110)，並且響應於將當前視頻段傳送給節點130-a的http請求來發起在沿著覆蓋網絡100的頻道上的視頻段的流傳輸。如將在下面更詳細地討論的，poi內容伺服器通常將每個視頻段傳送給相同或附近的asn110中的多個發出請求的a節點130，並且這些a節點130將進而把視頻段推送給沿覆蓋網絡100的多個其他節點，得到在任何給定時間點被傳送到客戶端節點並從其中繼的視頻段的多個並發副本的「再分發」。
在這種情況下，a節點130-a將視頻段中繼給兩個其他a節點130，其中一個在asn110-c內，另一個跨對等點120到asn110-a。如上所述，虛擬數據幹線覆蓋網絡表示當在asn110內的和跨asn110的a節點130之間中繼視頻段時該視頻段將遵循的路由路徑。因此，在這種場景下，視頻段不僅在asn110-c內的多個a節點130之間進行中繼，而且也從asn110-a跨各個對等點120中繼到多個直接互連的asn(即，110-a、110-d、110-f和110-g)，從該多個直接互連的asn，跨虛擬數據幹線覆蓋網絡的多個跳進一步中繼到其他asn110。
如將在下面更詳細地解釋的，asn110內所需的a節點130的數量將取決於各種因素，例如該asn110內的其他客戶端觀看節點的數量以及它們的相對能力(由它們的分類、開放時隙的數量和隨時間監視到的性能度量來確定)。例如，asn110-b、110-f、110-i和110-j各自被示出為僅具有單個a節點130，即使它們具有不同數量的要饋送的其他客戶端節點(將asn110-f中的單個其他節點與asn110-i中的許多其他節點進行比較)。
雖然監視的節點的上遊帶寬是確定其將直接饋送多少個節點(即，將要使用多少個輸出時隙)的關鍵因素，但重要的是要認識到，考慮到這些中繼的實現的快速程度(通常在1ms以下)，asn110內的節點「鏈」(將視頻段從一個節點中繼到另一個節點，依此類推)的長度在很大程度上是無關緊要的。例如，asn110-i中的直接饋送外部asn110(asn110-g和asn110-j)中的兩個a節點以及asn110-i內的兩個b節點130的單個a節點使用4個輸出時隙(在本實施例中反映出相對較高的監視到的上遊帶寬)。然而，從asn110-i中的該單個a節點間接饋送的b節點140和c節點150的長鏈並不是其上遊帶寬的反映。
在每個asn110內，生成一個或多個群組覆蓋網絡(在該實施例中針對每個視頻段動態地重新配置)，以在該asn110內將視頻段從每個a節點(即群組覆蓋網絡的「根」節點)中繼給該群組覆蓋網絡內的各個b(以及b∶a)節點140和c節點150。雖然在asn110-c(與asn110-h中所示的兩個群組覆蓋網絡相比)中僅示出了一個群組覆蓋網絡，但是每個asn110內生成的群組覆蓋網絡的數量(以及每個群組覆蓋網絡的內部拓撲)將取決於各種因素，例如該asn110內的客戶端觀看節點的數量，以及當前性能度量和歷史性能度量、開放時隙的數量等。
如上所述，諸如asn110-b中的a節點130-b之類的客戶端節點可以從多個其他客戶端節點(在這種情況下，從不同asn(110-a和110-d)中的兩個其他a節點130)接收視頻段。在一個實施例中，出於性能原因，這兩個其他饋送節點向a節點130-b交替發送視頻段的塊，例如，因為這些塊跨越了其擁塞級別被連續監視的對等點120，如將更詳細地解釋的。在其他實施例中，這可以出於冗餘的目的而進行，例如，因為基於歷史性能度量(不同於對等點120的擁塞，或作為對等點120的擁塞的補充)，饋送節點的可靠性可能是有問題的。
監視性能度量、中繼視頻段和動態重新配置覆蓋網絡100的方法將在下文關於圖4更詳細地探討，這將在對實現這些方法的關鍵的客戶端側(圖2)和伺服器側(圖3)的功能組件的討論之後進行。
客戶流傳輸視頻設備
轉到圖2，客戶端設備200示出了本發明的客戶端流傳輸設備的關鍵組件的一個實施例。客戶端設備200可被實現為臺式計算機或膝上型計算機以及智慧型手機或其他行動裝置，或實際上能夠處理流傳輸內容(例如流傳輸視頻)的任何其它消費電子設備。客戶端設備200包括本領域公知的某些標準硬體和軟體計算組件以及相關外圍設備210，包括cpu212、存儲器214、作業系統216、網絡適配器217、顯示器218和相機219。客戶端設備200利用這些組件和外圍設備210連同某些標準庫220一起成為網絡節點，並且接收、顯示和在本發明的虛擬廣播系統的其他網絡節點之間中繼流傳輸視頻內容。
本發明利用實現網絡協議和其他可用於促進設備之間流傳輸視頻內容的功能的某些標準庫220(其也在大多數智慧型手機以及許多其他計算設備上發現)。例如，視頻內容可以在兩個智慧型手機用戶之間流傳輸，並在其行動網路瀏覽器上顯示，而無需任何插件。標準庫220包括webrtc222api(其促進用於流傳輸視頻內容的瀏覽器到瀏覽器的通信)、各種自適應流傳輸224實現(例如，hls、mpeg-dash和平滑流傳輸等(其使得能夠自動調整流傳輸比特速率以「適配」對客戶端帶寬和cpu容量的改變的實時檢測結果))、網絡套接字226協議(其促進單個tcp/ip連接上的快速雙向客戶端-伺服器通信)和http228(用網絡伺服器和客戶端網絡瀏覽器之間不怎麼頻繁的標準通信)。
客戶端設備200還包括標準播放器232(在一個實施例中，集成到標準html5網絡瀏覽器230中的標準視頻播放器)以查看或播放流傳輸數字內容。在其他實施例中，標準播放器232被集成到獨立的臺式機應用或智慧型手機app中。使用標準html5網絡瀏覽器230的一個優點是，許多標準庫220被設計為與網絡瀏覽器一起工作，且因此不需要任何插件或者獨立的臺式機應用或智慧型手機app原本需要的其他自定義功能。
此外，網絡瀏覽器還支持客戶端側腳本語言，例如javascript，它經常用於補充標準網絡瀏覽器功能(例如，從標準網絡伺服器作為網頁的一部分傳遞，而不需要任何客戶端瀏覽器插件)。在一個實施例中，客戶端設備200的非標準關鍵組件(包括通信器270、性能監視器240、接收機250、中繼器260和上載器280)在javascript中實現，並且內容陣列255由該javascript代碼生成和維護。然而，應當注意，在不背離本發明的精神的情況下，這些組件中的一些或全部可以以其他程式語言且在獨立的臺式機應用或智慧型手機app中實現。
標準庫220促進了包括視頻內容在內的內容的通用點對點(單播)流傳輸。客戶端設備200的非標準關鍵組件解決了本發明的虛擬廣播系統實現的數字內容傳送架構的客戶端側方面。在一個實施例中，流傳輸協議構建在webrtc222之上，其中內容的路由經由客戶端-伺服器架構進行集中，並且內容本身經由動態可重新配置的p2p覆蓋網絡以分布式方式(逐節點地推送)流傳輸。
客戶端設備200的用戶可能通過各種不同的方式首次遇到一個或多個內容頻道，例如，通過電子郵件中的連結或網頁上的連結，或者甚至是來自獨立的臺式機應用或智慧型手機app。在一個實施例中，虛擬廣播伺服器300(將在下面關於圖3更詳細地討論)向html5網絡瀏覽器230傳送具有頻道選擇的標準html5網頁。該「頻道網頁」包括由html5網絡瀏覽器230解釋以實現客戶端設備200的非標準組件的功能的專有javascript代碼，所述非標準組件的功能包括與信令伺服器330以及其他客戶端節點通信(例如，使用webrtc222和自適應流傳輸224庫)，以及接收、處理以及從這些節點和向這些節點中繼視頻段的塊。
在點擊頻道網頁中的頻道連結時，用戶生成加入當前正在流傳輸的視頻內容的特定頻道的請求，或者在另一個實施例中，將在稍後的預定義時間點開始流傳輸(「加入請求」)。虛擬廣播伺服器300的信令伺服器330通過嘗試經由通信器270建立與客戶端設備200的網絡套接字226連接來響應加入請求。如下面將關於圖3更詳細地討論的，虛擬廣播伺服器300使用「stun」322協議來發現客戶端設備200的公共ip地址(例如，在nat防火牆之後)，以便客戶端設備200可以建立與虛擬廣播伺服器300的網絡套接字226連接，以及與其他客戶端設備200的webrtc222連接，以用於接收和中繼視頻內容。
在本文討論的實施例中，客戶端設備200在任何給定時間僅加入一個視頻頻道。在其他實施例中，客戶端設備200可以同時加入多個頻道，而不背離本發明的精神。
客戶端設備200利用通信器270與信令伺服器330進行雙向通信，以便於在保持單個tcp/ip連接打開的同時快速交換消息。如將在下面更詳細地討論的，這種通信被用於各種目的，包括：(i)向虛擬廣播伺服器300提供關於客戶端設備200能力的初始信息(例如，os、網絡瀏覽器和連接類型(3g、4g、wifi、lan等))，(ii)使虛擬廣播伺服器300能夠驗證客戶端節點連接，以用於後續的視頻段經由覆蓋網絡100的webrtc222節點間流傳輸，以及(iii)與虛擬廣播伺服器300交換實時動態監視信息(經由性能監視器240獲得，如下所述)。
在一個實施例中，包含在頻道網頁中的該javascript代碼還分析了客戶端設備200的能力，以確定它是否是c節點(其接收視頻段但不將它們中繼到其他客戶端節點)，並將該信息提供給信令伺服器330。在其他實施例中，客戶端設備200的某些能力被發送給虛擬廣播伺服器300，虛擬廣播伺服器300確定客戶端設備200是否是c節點。
該javascript代碼還便於與poi內容伺服器380的通信，以管理接收機250對視頻段的接收，以供標準播放器232播放。該過程實際上是標準點對點視頻流傳輸場景的擴展，其利用標準webrtc222和自適應流傳輸224功能。
在一個實施例中，標準網絡瀏覽器230解釋來自頻道網頁的專有javascript代碼以如上所述地周期性請求清單文件。這樣的標準http請求被定向到提供清單文件的poi內容伺服器380。標準網絡瀏覽器230還利用標準自適應流傳輸224庫向清單文件中指定的位置請求視頻段本身，包括如上所述的這些視頻段的更高或更低比特速率版本(例如，當檢測到帶寬改變時)。
針對視頻段的這些請求被來自頻道網頁的專有javascript代碼攔截，即，因為每個視頻段是從覆蓋網絡100的另一(饋點)節點向客戶端設備200推送的(消除了對客戶端設備200發起http「拉」請求的需求)。在一個實施例中(下面更詳細地討論)，虛擬廣播伺服器300在接收到加入請求之後不久將客戶端設備200添加到覆蓋網絡100(並且因此添加到頻道)，使得一個或多個初始視頻段將被推送到客戶端設備200，以使其能夠儘快開始播放視頻內容。
隨著接收機250接收每個視頻段的塊，它生成內容陣列255，以便於視頻段的接收和回放，以及將視頻段(如果客戶端設備200未被指定為c節點)中繼到其他客戶端節點。接收機250生成接收陣列256以將塊彙編成完整的視頻段，該視頻段被提供給由標準播放器232維護的三段緩衝器(three-segmentbuffer)。如果在攔截針對視頻段的http請求時，接收機250確定完整視頻段尚未在接收陣列256中，則將向清單文件中指定的備選(或「回退」)位置(即，poi內容伺服器380)請求該視頻段。從標準播放器232的角度來看，它響應於標準的http請求而接收視頻段，並且不知道視頻段實際上被經由覆蓋網絡100推送給客戶端設備200。
此外，在一個實施例中，接收機250還利用自適應流傳輸224庫來將客戶端設備200可以處理的比特速率(無論標準播放器232是否以正常方式經由清單文件作出這樣的請求)傳遞給信令伺服器330(經由通信器270)。例如，如果客戶端設備200經歷其帶寬的臨時顯著下降(導致視頻段未在需要之前到達接收陣列256)，則它可以向poi內容伺服器380請求一個(回退)視頻段，然後通過覆蓋網絡100推送後續的低解析度視頻段。一旦其比特速率恢復正常，則其可以如同發生問題之前一樣推送更高解析度的視頻段。
如上所述，在一個實施例中，虛擬廣播伺服器300針對每個視頻段動態重新配置覆蓋網絡100，包括虛擬數據骨幹覆蓋網絡(在asn內和跨asn的a節點之間)和群組覆蓋網絡(從asn內的每個a節點到該asn內的其他節點)。除非客戶端設備200被分類為c節點(其接收視頻段但不將其中繼給其他客戶端節點)，否則，中繼器260將從虛擬廣播伺服器300接收關於它將會把該視頻段中繼到的哪個或那些節點的指令(針對其加入的視頻頻道的每個視頻段)。如上參考圖1所討論的，無論客戶端設備200是a節點、b∶a節點還是b節點，都可被要求將視頻段中繼給多個其他客戶端節點。
視頻段的長度(例如，從1秒到10秒)由視頻內容的發起者根據自適應流傳輸224標準來定義。中繼器260將通過根據webrtc222標準的「rtcdatachannel」組件(其不強制執行信令協議)推送塊來將視頻段中繼給每個指定的目的地客戶端節點。
在一個實施例中，當通過mpeg2傳輸協議流傳輸時，每個視頻段被劃分成64kb的塊以匹配udp數據報(分組)的大小，以獲得最大的效率。客戶端設備200每次一個塊地發送和接收udp「分組」(根據webrtc222標準，在需要時回退到tcp)。例如，1秒的視頻段將包含大約625個塊(假定為1080p的h.264編碼器，其產生大約5000kbps)。
隨著接收機250接收每個視頻段的塊，它生成接收陣列256，以彙編這些塊並構建完整的視頻段。中繼器260生成中繼陣列257以彙編這些塊，以便將它們發送(中繼)給指定的目的地客戶端節點。通過這種方式，中繼陣列257擔當視頻段的輸入塊和輸出塊的緩衝器。如下面將討論的，性能監視器240跟蹤將整個視頻段傳送到每個指定的目的地客戶端節點所需的時間，並將該度量報告回虛擬廣播伺服器300(以用於動態重新配置覆蓋網絡100中的後續使用)。
在一個實施例中，接收客戶端節點從單個饋送節點(例如客戶端設備200)接收視頻段。在另一個實施例中，虛擬廣播伺服器300選擇多個潛在饋送節點，並且它們之間進行通信以協商「前兩個」候選(例如，基於當前帶寬或其他所監視的性能度量)，且然後向指定的接收客戶端節點交替地發送塊。
在另一個實施例中，在a節點之間推送每個視頻段的多個不同解析度(例如，1080p、720p和480p)，並且虛擬廣播伺服器300指向每個群組覆蓋網絡的根部處的具有這些解析度的a節點，以向該群組覆蓋網絡內的其他節點推送(例如，基於那些其他節點的能力，如下文更詳細討論的)。
在接收機250正在接收用於回放的視頻段的塊並且中繼器260正在將這些塊流傳輸給其他指定的客戶端節點期間，性能監視器240收集虛擬廣播伺服器300所指向的各種靜態和實時的動態性能度量，並且經由信令伺服器330連續地將這些度量提供回虛擬廣播伺服器300。
如上所述，虛擬廣播伺服器300使用這些度量來動態地重新配置覆蓋網絡100，以優化下一視頻段的路由。特別地，性能度量被用於對客戶端節點進行分類和重新分類，對用於將視頻段中繼給其他客戶端節點的時隙進行分配和解除分配，確定視頻段的哪些解析度可被接收並中繼給其他客戶端節點，以及最終在覆蓋網絡100被動態重新配置時修改客戶端節點之間的路由路徑的子集。以下將參考圖3更詳細地討論虛擬廣播伺服器300利用這些性能度量的精確方式。
靜態性能度量(例如作業系統、瀏覽器和連接的類型(例如，3g或4g蜂窩、wifi、lan等)不太可能頻繁改變，並且通常僅在客戶端設備200請求初始加入時才向信令伺服器330報告(儘管其在發生改變的情況下將被報告，所述改變如從3g到4g的蜂窩連接改變)。
當動態信息可以連續收集和報告時(即當其被搜集時)，在一個實施例中會考慮到各種折中，以確保「開銷」(監視並向信令伺服器330的報告這些動態度量的頻率)不影響視頻本身的傳送(即，向客戶端設備200流傳輸塊和從客戶端設備200流傳輸塊)的「有效載荷」或性能。在一個實施例中，這樣的度量僅用於下一個視頻段，而在其他實施例中，當前視頻段的傳送期間的下一個塊(或多個塊)可能會受影響發生改變。
在一個實施例中，執行兩種類型的動態性能監視。第一種類型涉及對在網際網路上的位於客戶端設備200所在的asn內部和跨asn的已知站點(例如，對yahoo網絡伺服器、虛擬廣播伺服器等)的「ping」時間(或其他類似的測量)。分別地，這樣的度量提供對客戶端設備200的性能的洞察，同時它們提供了對在客戶端設備200所駐留的asn內以及經由特定對等點跨asn的qos的附加洞察。雖然虛擬數據骨幹覆蓋網絡(在a節點之中)相對更加引人關注(由於對等點處的擁塞)，asn內的擁塞也是有意義的(因為，例如可能需要動態重新配置asn內的一個或多個群組覆蓋網絡的至少一部分)。
另一種類型的動態性能監視涉及將視頻段從一個客戶端節點中繼到另一個客戶端節點所需的總時間。在一個實施例中，每個節點(c節點除外)記錄將視頻段的第一塊發送給指定的目的地客戶端節點時的「開始」時間，以及在接收到該視頻段的最後一個塊後的「停止」時間(例如，因為webrtc222標準提供每個分組的驗證)。性能監視器240將(針對其發送的每個視頻段的)該總時間發送給信令伺服器330。該度量還可以提供不僅與客戶端設備200的單獨性能有關而且與其asn內和跨asn的擁塞級別有關的洞察(例如，如果客戶端設備200是跨asn對等點向另一a節點饋送的a節點)。
在一個實施例中，客戶端設備200的用戶也可以是視頻內容的發起者。在大多數情況下，這種場景是由於智慧型手機相機(例如相機219)的質量不斷提高，使用戶可以「隨時隨地」捕捉視頻事件。但是，臺式機計算機或膝上型計算機以及智慧型手機的用戶也可能從其他來源獲得預先錄製的視頻事件。
問題是，客戶端設備200必須以某種方式將其視頻內容通過網際網路流傳輸給虛擬廣播伺服器300，該虛擬廣播伺服器300可能跨多個asn相距許多跳。上載器280經由專有「淋浴」協議解決了這個問題，以避免在中間路由器處udp分組被延遲或阻塞。在一個實施例中，上載器280通過客戶端設備200上的專用智慧型手機app來實現，而不是依賴於更有限的客戶端側javascript功能。
為了實現這種淋浴協議，上載器280與虛擬廣播伺服器300建立tcp/ip連接，並採用udp「突發」來傳送可用的最大ip分組大小(「最大傳輸單元」或mtu)。然而，連續的udp流(無論是經由單個路由器埠發送還是分布在多個路由器埠上)通常將被中間路由器檢測為「拒絕服務」(dos)攻擊，並從而被阻塞。此外，這樣的udp流可能溢出路由器的所分配的存儲器(例如，fifo隊列)，因為路由器通常只在接收到udp分組(而不是更常見的tcp分組)時才為udp分組分配存儲器。
為了解決這些障礙，上載器280不僅在多個埠(例如，在一個實施例中，6個埠)中分布udp分組，還延遲在任何單獨埠上發送的分組，以避免被檢測為dos攻擊。在一個實施例中，每個埠上的延遲長得足以避免被檢測為dos攻擊，並且長得足以使得路由器能夠分配足夠的存儲器，但短得足以提供足夠的帶寬以跨多個asn傳送視頻段，並且短得足以避免被視為udp流的結束(這將導致路由器停止為udp分組分配內存，並且基本上「將其丟棄」)。
當上載器280以這種方式將每個視頻段傳送給虛擬廣播伺服器300時，虛擬廣播伺服器300然後生成頻道，以便沿著覆蓋網絡100重新分布該視頻內容，就好像其已經從更傳統的cdn接收到的那樣。在另一個實施例中，虛擬廣播伺服器300在相對不常見的場景中使用這種專有的淋浴協議，在該場景中，它是針對當前視頻段沿著覆蓋網絡100沒有及時到達的客戶端節點的視頻段的回退起點源。
虛擬廣播伺服器
圖3示出本發明的虛擬廣播伺服器300的關鍵伺服器側組件的一個實施例。如上所述，雖然虛擬廣播伺服器300的組件被示出在單個物理硬體伺服器中，但是在不背離本發明的精神的情況下，可以在多個不同的物理硬體設備和不同的軟體模塊之間重新分配這些組件的功能。
虛擬廣播伺服器300包括在大多數硬體伺服器中發現的某些標準功能，例如標準hw/sw310，如cpu312、存儲器314、作業系統316、網絡適配器317和顯示器318。在某些實施例中，虛擬廣播伺服器300還利用標準庫320，標準庫320可以包括例如：(i)stun322協議(「用於nat的會話遍歷實用程序」)，其便於發現在nat防火牆之後的客戶端設備200的公共ip地址，使客戶端節點可以向其他客戶端節點發送視頻和從其他客戶端節點接收視頻，並建立與虛擬廣播伺服器300的連接；(ii)網絡套接字326協議，其有利於通過單個tcp/ip連接的快速雙向客戶端-伺服器通信；以及(iii)http328，其被用於與客戶端網絡瀏覽器(例如，標準的html5網絡瀏覽器230)的不怎麼頻繁的標準通信。
虛擬廣播伺服器300不需要支持webrtc222和自適應流傳輸224標準，因為它不是覆蓋網絡100上的客戶端節點，儘管它不斷分析從客戶端節點獲得的性能度量，並動態地重新配置視頻內容頻道的在沿覆蓋網絡100的這些客戶端節點之間分布的路由路徑。
虛擬廣播伺服器300擔當覆蓋網絡100(具體地，虛擬數據骨幹覆蓋網絡)的「頻道發起者」起點。在一個實施例中，poi內容伺服器380指定一個或多個附近的a節點(優選地在其asn中，如果可能的話)來發布對視頻段的http請求。這些a節點有效地擔當虛擬數據骨幹覆蓋網絡的根部，且將每個視頻段推送給asn內和跨asn的其他a節點，並最終經由每個asn內的群組覆蓋網絡推送給其他節點。
如將在下面參考poi內容伺服器380更詳細地描述的，這種「頻道發起」功能不需要使用針對瀏覽器到瀏覽器視頻流傳輸的標準webrtc222和自適應流傳輸224庫。如上所述，poi內容伺服器380還擔當未及時接收沿著覆蓋網絡100的當前視頻段的客戶端節點的偶爾的備選(回退)視頻段來源。這樣的客戶端節點發出http請求，poi內容伺服器380通過向這樣的客戶端節點發送所請求的視頻段來響應該http請求。
如上所述，poi內容伺服器380擔當所有視頻頻道的起點(在一個實施例中)，無論視頻內容是經由上載器280從客戶端設備200獲得的，還是從更傳統的cdn獲得的(以及無論是向虛擬廣播伺服器300實時流傳輸的，還是提前提供以在稍後流傳輸的)。
頻道管理器385負責設置和維護每個頻道，而poi內容伺服器380準備視頻內容本身以作為頻道向客戶端節點流傳輸。在一個實施例中，頻道管理器385生成並維護頻道網頁，以由poi內容伺服器380通過網際網路傳送，且由信令伺服器330在響應來自客戶端設備200的尋求加入具體頻道的加入請求時使用。
為了支持目的，頻道管理員385建立和維護「查看器支持控制臺」，以支持其客戶端設備200遇到問題的個人觀眾以及用於實時監視所有視頻頻道的「播出中心」可以解決信道特定的且區域特定的問題(例如，由特定地理區域產生的支持呼叫)。頻道管理器385還維護對「頻道分析」的實時監視，以提供對這些支持功能以及視頻內容的發起者(例如在cdn處)有用的數據。例如，分析包括關於下述方面的實時度量：每個視頻頻道和沿覆蓋網絡100的網絡節點的當前狀態，以及與視頻比特速率、擁塞點、節點等待時間等相關的最後一英裡問題，等等。
最後，提供「頻道管理」功能來管理視頻頻道並與信令伺服器330進行接口連接，使得其具有促進其與客戶端設備200通信所必需的當前信息(例如，關於加入頻道，提供所監視的客戶端的性能度量，獲得中繼目標的路由以及解析度或比特速率變化等)。
除了潑濺提取器390以外，為了簡單起見，將在單個視頻內容頻道的上下文中描述圖3所示的剩餘的伺服器側功能。然而，請注意，在一個實施例中，該功能是在任何給定時間針對多個頻道以及各種數字內容並發執行的。
在客戶端節點訪問視頻頻道之前，視頻內容被轉碼以創建多個較低解析度的視頻段流。在一個實施例中，poi內容伺服器380被實現為能夠與客戶端設備200內的標準html5網絡瀏覽器230通信的http228伺服器。與信令伺服器330(其與客戶端設備200建立用於頻繁雙向通信的網絡套接字225連接(例如交換路由更改、性能數據等))不同，poi內容伺服器380對來自標準html5網絡瀏覽器230的相對不頻繁的客戶端http228請求做出響應，所述客戶端http228針對清單文件、偶爾的未及時經由覆蓋網絡100到達的視頻段等等。
如上所述，poi內容伺服器380還依賴於http228協議來實現其較高帶寬頻道發起功能，即，通過響應來自附近a節點(在虛擬數據幹線覆蓋網絡的根部處，通常在與poi內容伺服器380相同的asn中，或者在一或兩跳內)的針對視頻段的http請求。在其他實施例中，這些視頻段按照webrtc222和自適應流傳輸224標準被推送給這些a節點，或者經由其他視頻流傳輸技術(包括如上所述的由上載器280使用的淋浴協議)被推送給這些a節點。
在一個實施例中，poi內容伺服器380將視頻內容轉碼為3種不同解析度(1080p、720p和480p)，而在其他實施例(例如，4k、360vr、180vr、240p等)中支持各種其它較高和較低解析度，包括所有視頻內容的單一固定解析度。如果以較低解析度(例如，720p)提供原始源視頻，則針對該視頻頻道僅可支持720p和480p解析度。該功能有助於自適應比特速率流傳輸，無論是由客戶端節點(如上所述)發起還是由虛擬廣播伺服器300基於客戶端性能度量的分析來發起。
在一個實施例中，poi內容伺服器380通過響應http請求來發起頻道，以將每個視頻段的所有可用版本(例如，3個不同的解析度)提供給一個或多個附近節點(通常為a節點)，該附近節點發起每個視頻段的沿著覆蓋網絡100的推送。在另一個實施例中，這些節點將所有版本中繼給b節點(以及b∶a節點)，並且最終中繼給c節點，使得每個客戶端節點可以利用自適應流傳輸224能力。將多個解析度中繼給其他節點的節點通過覆蓋網絡100將這些多個版本的視頻段「聚播」給其他客戶端節點，如下面更詳細地解釋的。
注意，雖然poi內容伺服器380通過向一個或多個附近節點(響應於http請求)提供視頻段來發起頻道，但假設每個視頻段在之前的視頻段的回放已經結束之前穿過覆蓋網絡100，所有客戶端觀看節點同時有效地接收和查看每個視頻段，即，它們都是同步的。因為本實施例中客戶端設備200緩衝至少3個視頻段，所以如果視頻段偶爾被延遲，該緩衝器提供一些「出錯餘地」。此外，在另一實施例中，當poi內容伺服器380首先開始「廣播」頻道時，可以延遲頻道的發起以提供附加的緩衝。當客戶端設備200直接從回退poi內容伺服器380發出對視頻段的請求時(例如，因為視頻段沒有經由覆蓋網絡100及時到達)，例如，如果該視頻段跨一個或多個asn，則可能需要該緩衝器。
如上所述，poi內容伺服器380還響應於來自客戶端設備200的請求提供周期性清單文件。雖然這些清單文件是通過標準http328協議提供的，但它們與視頻段相比相對較小且時間關鍵性低很多。在一個實施例中，每個清單文件識別接下來的8個視頻段的各種可用比特速率的位置。在該實施例中，該位置是關於poi內容伺服器380的回退位置，因為視頻段經由覆蓋網絡100被推送給每個客戶端設備200。
一旦視頻內容的頻道已準備好用於流傳輸(從poi內容伺服器380開始)，信令伺服器330等待來自客戶端設備200的加入請求。在從客戶端設備200接收到針對該頻道的加入請求時，信令伺服器330依賴於stun322協議來確保它可以通過可能存在於該客戶端設備200上的任何nat防火牆來建立網絡套接字326連接。此外，通過識別該客戶端設備200的公共ip地址，可以將該公共ip地址提供給其他客戶端節點(例如，用於將視頻段中繼給該客戶端設備200)。
一旦建立了網絡套接字326連接，客戶端設備200向信令伺服器330提供關於其能力(例如，os、網絡瀏覽器和連接類型(3g、4g、wifi、lan等))的信息，在一個實施例中，包括客戶端設備200是否是c節點(例如，在本實施例中假定用於蜂窩連接)。客戶端設備200還向信令伺服器330提供其asn位置，該asn位置稍後將用於將客戶端設備200添加到覆蓋網絡100。
在一個實施例中，信令伺服器330將去往客戶端設備200的一個或多個初始視頻段的傳送(經由覆蓋網絡100)進行優先化，使得其可以儘快開始播放頻道的視頻內容。為了發起此過程，它將控制權轉移到覆蓋網絡創建器350，覆蓋網絡創建器350將客戶端設備200添加到其asn內的群組覆蓋網絡(例如，通過指示該asn內的b節點將視頻段中繼給客戶端設備200)。注意，客戶端設備200尚未被分類，並且還不會將任何視頻段中繼給其他客戶端節點，但是通過成為覆蓋網絡100的一部分，客戶端設備200可以開始接收視頻段並播放頻道的視頻內容，以及收集將便於其分類的客戶端性能度量。
信令伺服器330隨後通過其網絡套接字326連接獲得客戶端設備200的上遊和下遊帶寬。注意，該度量不是非常有用的，因為連接可以跨多個asn(即使信令伺服器330知道客戶端設備200的asn位置)。更相關的度量將涉及客戶端設備200與其自己的asn內的其他客戶端節點之間的通信。
在從客戶端設備200(以及從其他客戶端節點)接收客戶端性能信息(由客戶端設備200上的性能監視器240收集)時，信令伺服器330將該信息轉發給性能跟蹤器340，以便覆蓋網絡創建器350和深度映射器360在動態重新分類客戶端節點並為下一個視頻段重新配置覆蓋網絡100時進行初步分析和後續使用，如下所述。性能跟蹤器340監視每個客戶端節點的性能，並確定客戶端節點是否仍然「活著」。例如，如果客戶端設備200已經關閉了連接並離開了頻道，或者在閾值時間量內沒有響應「ping」，則將被視為已經離開該頻道(無論是有意地還是由於硬體或軟體故障)。性能跟蹤器340還將客戶端性能度量轉換為用於存儲在歷史性能db345中的適當格式，並由覆蓋網絡創建器350和深度映射器360使用。
在一個實施例中，覆蓋網絡創建器350還在深度映射器360的幫助下負責評估當前的和歷史的客戶端性能度量(維護在歷史性能db345中)的連續過程，並針對每個視頻段動態地(i)重新分類客戶端節點，以及(ii)通過生成和重新配置覆蓋網絡100(包括虛擬數據幹線覆蓋網絡(用於在asn內和跨asn的a節點之間中繼視頻段)和群組覆蓋網絡(用於從asn內的每個a節點將視頻段中繼給該asn內的某些其他b∶a、b和c節點))來優化路由路徑。覆蓋網絡100的拓撲被維護在覆蓋網絡db375中，供覆蓋網絡創建器350和深度映射器360使用。
對於從新添加的客戶端設備200接收到的性能度量，覆蓋網絡創建器350利用這些度量來初始地分類客戶端設備200。在一個實施例中，該過程還用於針對每個視頻段潛在地重新分類客戶端節點(不僅僅是當他們加入頻道時)。雖然客戶端節點通常不經常被重新分類，但客戶端可能經歷帶寬的暫時下降(例如，來自家庭微波或其他幹擾)。此外，由於需要更多的a節點(例如，為了冗餘，或由於離開頻道的客戶端節點)，b∶a節點可升級為a節點。在asn內或跨asn檢測到的其他問題也可能要求將某些節點重新分類。
覆蓋網絡創建器350向客戶端設備200分配輸入時隙和輸出時隙(即，網絡埠)，使得其可以(經由輸入時隙)接收從其他客戶端節點推送的視頻段的塊，並且可以(經由輸出時隙)中繼(推送)視頻段的這些塊給其他客戶端節點。雖然webrtc224標準支持256個輸入和輸出埠(時隙)，但是在一個實施例中僅分配單個輸入時隙(以最大化可在客戶端設備200上播放的視頻內容的質量)，並且分配最多8個輸出時隙(以最大化沿覆蓋網絡100的吞吐量，並支持廣泛的客戶端設備200和有限帶寬連接)。如上所述，a節點被分配4個輸出時隙用於將視頻段跨asn對等點中繼給其他a節點，以及4個輸出時隙用於將視頻段中繼給其asn內的其他a節點。如下面將要解釋的那樣，在任何給定的時間點並不是所有分配的時隙必然被使用。
覆蓋網絡創建器350分析客戶端設備200的下遊帶寬和上遊帶寬以便於分類過程如上所述，如果客戶端設備200通過蜂窩連接(3g、4g或甚至lte)加入，則其自動被認為太不可靠而不能中繼視頻段，並因此被分類為c節點。在其他實施例中，這種自動分類可被限於某些蜂窩連接(例如，3g)，或被完全消除。
在一個實施例中，覆蓋網絡創建器350採用典型的下遊/上遊帶寬(以mbps為單位)的類別以便於進一步分類，包括：(1)lan連接(例如100/100)，(2)光纖連接(100/50)，(3)adsl連接(100/20)、線纜連接(100/10)和wifi連接，其差別很大。在該實施例中，如果客戶端設備200尚未被認為是c節點，並且具有至少50mbps的上遊帶寬，則其最初被分類為a節點(或者如果深度映射器360指示其asn中不需要附加的a節點，分類為b∶a節點)。否則，它將被分類為b節點。
如下面將要討論的，覆蓋網絡創建器350還分析客戶端設備200的上遊帶寬(在一個實施例中)，以計算在其確定其應該動態重新配置覆蓋網絡100的程度(如果有的話)之前其可以利用的可用輸出時隙的數量。它還確定客戶端設備200能夠接收和/或聚播多個解析度的程度。
在一個實施例中，客戶端節點的完整下遊帶寬用於其單個輸入時隙，而其上遊帶寬的僅1/3用於在其輸出時隙之間中繼視頻段。由於視頻段的中繼可能會干擾客戶端設備200正在為其他應用使用的tcp/ip連接和其他連接，因此不會利用其完整的上遊帶寬。
覆蓋網絡創建器350分析客戶端設備200的下遊帶寬(即使被分類為c節點)來確定其可以通過其單個輸入時隙支持的解析度數量。例如，如果1080p需要3mbps的比特速率，720p需要1.5mbps的比特速率，且480p需要500kbps的比特速率，那麼客戶端設備200將需要至少5mbps的下遊帶寬來支持所有3解析度，至少4.5mbps支持1080p和720p，至少3mbps僅支持1080p，至少2mbps支持720p和480p，至少1.5mbps僅支持720p，至少500kbps僅支持480p。在一個實施例中，不支持低於500kbps的比特速率。在其他實施例中，可以支持更低的解析度，並且可以採用其他技術(例如更大的壓縮，不同的視頻格式等)來放寬帶寬要求。
如上所述，在一個實施例中，a，b∶a和b節點也可被認為是可以經由其一個或多個輸出時隙將多個解析度中繼給其他節點的聚播節點。在這方面，覆蓋網絡創建器350分析客戶端設備200的上遊帶寬以確定其可以中繼給其他客戶端節點的解析度的數量。
由於客戶端節點在該實施例中僅可以利用其上遊帶寬的1/3，所以客戶端設備200將需要至少15mbps(針對每個輸出時隙)的上遊帶寬以聚播所有3個解析度，至少13.5mbps(針對每個輸出時隙)以聚播1080p和720p，至少9mbps(針對每個輸出時隙)僅發送1080p，至少6mbps(針對每個輸出時隙)以聚播720p和480p，至少4.5mbps(針對每個輸出時隙)僅中繼720p，以及至少1.5mbps(針對每個輸出時隙)以僅中繼480p。
客戶端設備200不能中繼其沒有接收到的解析度。此外，如下所述，結合其他客戶端節點接收多個解析度的能力來考慮客戶端設備200的聚播能力。但是，如上所述，客戶端設備200使用自適應流傳輸224實現來在視頻段經歷其帶寬的顯著變化時請求更低或更高解析度的視頻段版本如果它接收到視頻段的多個不同解析度，它將簡單地播放它接收到的最高解析度。
假設客戶端設備200不是c節點，則覆蓋網絡創建器350通過分析其上遊帶寬並考慮其可以聚播多個解析度的程度來計算其可以利用的可用輸出時隙的數量。例如，如果客戶端設備200被分類為具有上遊帶寬為100mbps的lan連接的a節點，則它可以僅利用約6個輸出時隙以在asn內和跨asn聚播視頻段。在該實施例中，覆蓋網絡創建器350將分配4個時隙用於跨asn向其他a節點進行聚播(給出這些asn間時隙優先級)，留下2個剩餘的時隙用於向其asn內的其他a節點進行聚播。在其他實施例中，當然可以在不背離本發明的精神的情況下改變這些分配。
類似地，如果客戶端設備200被分類為具有10mbps的上遊帶寬的電纜連接的b∶a或b節點，則它可以僅使用1個輸出時隙來聚播720p和480p解析度，或者僅發送1080p。在一個實施例中，給予更高質量的解析度(在節點可以接收該解析度的情況下)以優先，因此一個時隙將僅被分配用於1080p。這些分配也可以在不背離本發明的精神的情況下變化。
在已經分類了客戶端設備200並且確定了可以利用的時隙數(包括聚播多個解析度)，覆蓋網絡創建器350然後確定其將動態重新配置覆蓋網絡100以優化路由路徑的程度。如果客戶端設備200是a節點，則覆蓋網絡創建器350將首先從深度映射器360獲得針對a節點之間的每個asn間路徑的擁塞級別(如下面更詳細地討論的)，然後將會動態重新配置至少部分的虛擬數據幹線覆蓋網絡以包含客戶端設備200。
例如，給定加權路徑集合(每個路徑具有「擁塞級別」加權)，覆蓋網絡創建器350使用標準路徑查找技術來確定用於在a節點之間分發視頻段的最佳路徑(類似於例如gps導航路由)。然而，要注意，通過使用多個中繼時隙(例如，a節點用於中繼到asn內的a節點的4個輸出時隙，以及a節點用於跨asn對等點中繼到a節點的4個輸出時隙)，該過程稍微複雜化。然而，這僅僅是a節點僅具有1個輸出時隙的最簡單情況的輕微變化。換句話說，覆蓋網絡創建器350跟蹤在虛擬數據幹線覆蓋網絡的生成或重新配置期間所開放的(未使用)時隙的數量，並且一旦特定的a節點不再具有任何未使用的開放時隙就停止將其指派為中繼源。
如果客戶端設備200是b∶a或b節點，則覆蓋網絡創建器350動態地重新配置客戶端設備200所駐留的asn中的asn內群組覆蓋網絡中的一些或全部。要注意，如果該asn內有多個a節點，則它們彼此之間的路由將被確定為虛擬數據幹線覆蓋網絡的一部分。在一個實施例中，將僅使用一個a節點來創建群組覆蓋網絡(如果有足夠的時隙可用)，而在其他實施例中，可以在多個a節點之間平等地分配該其他節點，或者基於相對上遊帶寬或其他度量來分配該其他節點。
對於任何特定的a節點，以及asn內的剩餘b，b∶a和c節點，這些節點首先基於其分類(即b∶a，然後b，然後c)並然後基於其相對帶寬進行排名(即，可以利用的可用時隙的數量，如上所述)。注意，考慮到每個節點僅具有單個饋點節點，在該實施例中，群組覆蓋網絡是分層結構。在其他實施例中，類似的技術可以用於非分層「網格」群組。
在該分層群組實施例中，該過程以根部a節點開始，該然後基於它們相對帶寬將會具有可被利用的一定數量的輸出時隙(例如，2個輸出時隙)。這些時隙將被路由到層次結構的下一級，例如具有可被利用的最多可用時隙數的2個b∶a節點。一旦確定了這些路徑，這些節點的可用輸出時隙將被路由到具有最多可用時隙的剩餘b∶a節點。該過程繼續在層級中下降(通過b節點，且最後是c節點)，直到所有路徑都被確定為止。
注意，在asn內的節點之間的中繼具有相對較高的速度(遠低於1毫秒)的情況下，在任何客戶端節點(例如，各自具有單個輸出時隙的100個客戶端節點)下的鏈的長度具有相對較小的關注度。給定1秒的視頻段，仍然可以容納數百個節點的鏈(儘管它們將是罕見的，因為asn內的許多節點可能會支持多個輸出時隙)。在所有節點不能被包括在群組中的情況下(例如，如果具有0個可用時隙的c節點和b節點保持不計算在內)，則將需要在該asn中具有開放時隙的附加節點，該附加節點將會當他們可用時被分配。在此期間，這樣的節點將被引導以向poi內容伺服器380請求視頻段。
在轉向深度映射器360之前(該映射器預測並量化跨asn對等點的擁塞級別(例如，針對下一分鐘))，了解bgp路由協議的局限性以了解asn對等點擁塞的重要性是有幫助的。bgp路由器確定「路由時間」處的擁塞，並且沒有預測能力。他們只知道自己的路由器，並且跨asn對等點等待時間「1跳」。他們不知道到任何最終目的地的跳數或等待時間，這可能是跨多個asn對等點相距多跳。給定多個asn對等點的選擇，他們基本上選擇當前具有最多可用帶寬的那個(即，具有開放時隙且最短等待時間1跳的那個)。
相比之下，深度映射器360利用其對網際網路底層架構的了解。在一個實施例中，如圖1所示，深度映射器360維護網際網路(包括asn及其各種對等點互連)的asn互連地圖，如圖1中粗略所示。該地圖不會頻繁變化，儘管在一個實施例中，每5分鐘對其監視一次以捕捉這種不頻繁的變化。
然而，在這些asn之上構建的覆蓋網絡100被頻繁地分析(例如，通過如上所述的客戶端側監視)，並且潛在地由虛擬廣播伺服器300針對每個視頻段來重新配置(例如，在一個實施例中，每一秒)。然而，實際上，覆蓋網絡100實際上僅在有保證的情況下進行修改，例如，不僅當新節點加入或離開頻道時，而且當檢測到足夠的問題(基於歷史性能db345中維護的當前信息和歷史信息)時。
例如，在一個實施例中採用多個內部「擁塞閾值」。在初始檢測到特定於具體客戶端設備200或asn內的擁塞相對較低的閾值時，覆蓋網絡創建器350僅「標記」客戶端設備200或asn，並且等待以看該問題是否重現(例如，在下一個視頻段上)。如果重現，它可能會降低中繼給該客戶端節點(或該「問題」asn內的所有客戶端節點)的下一個視頻段的解析度(以及因此的比特速率)。最終，如果問題變得更糟(例如，超過較高的擁塞閾值)，則覆蓋網絡100的一部分(例如，asn內的子集ip範圍)可被動態地重新配置。最後，整個asn或者可能虛擬數據幹線覆蓋網絡本身可能需要動態重新配置。
無論如何，這些擁塞閾值的目的是在問題惡化到導致視頻段丟失或者甚至導致客戶端節點不得不從poi內容伺服器380的回退位置獲得視頻段的更嚴重問題之前，主動地識別和糾正問題。
通過保持知道網際網路的asn互連地圖以及覆蓋網絡100上節點的asn位置，並實時監視這些節點的當前和歷史性能，深度映射器360最小化了任何客戶端節點會不必要地將視頻段中繼給遠程客戶端節點(例如，跨多個asn對等點相距許多跳)的可能性。例如，在一個實施例中，作為初始事項，虛擬數據幹線覆蓋網絡將傾向於將視頻段(每當有可能)從一個a節點路由給相同asn中的另一個a節點或跨單個asn對等點的附近asn的另一a節點。
但是，並不是所有的單跳都是平均創建的。例如，深度映射器360可以隨著asn1和asn2之間的對等點變得擁塞的時間進行「學習」(基於在歷史性能db345中維護的客戶端性能度量)，並且可以「預測」從「asn1」到「asn3」到「asn2」的2跳路由實際上比當前的1跳路由更快(或者基於最近趨勢和歷史趨勢在不久的將來會更快)。通過基於跨對等點的a節點的實際當前性能和歷史性能來量化對等點擁塞，深度映射器360可以促進虛擬數據幹線覆蓋網絡的拓撲的動態重新配置(潛在地針對每個視頻段，或者至少當對等點擁塞(基於內部閾值)需要這樣的改變時)。
在一個實施例中，採用1到10的範圍，深度映射器360針對每對a節點(無論它們是駐留在相同的asn還是在不同的asn中)對擁塞進行量化，其中，1是所預測的近期擁塞的最低級別且10是最高級別。如上所述，覆蓋網絡創建器350利用該擁塞級別「分數」來比較a個節點之間的不同潛在路由並且確定最有效的路由(即，最低的「加權跳」路由)。因此，與poi內容伺服器380相距最「遠」(在加權跳躍中)的a節點將最小化視頻段從poi內容伺服器380穿過虛擬數據幹線覆蓋網絡到這樣的a節點所需的時間量。
在一個實施例中，對於每對a個節點，深度映射器360生成針對從一個a節點到另一個a節點的每條路由的預測擁塞級別分數，然後選擇要應用於該a節點對的最低擁塞級別分數，該分數被其返回給覆蓋網絡350。在其他實施例中，深度映射器360生成那些預測的擁塞級別分數(針對從一個a節點到另一個a節點的每條路由)的不同函數，例如平均值，中位數等。
在一個實施例中，深度映射器360是連續分析在歷史性能db345中維護的性能度量的深度學習引擎，並且預測(例如，未來一分鐘)跨asn對等點的擁塞級別。應該注意的是，像任何深度學習引擎一樣，關於跨asn對等點的a節點之間的流量，深度映射器360採用多個非線性變換來對asn對等點的行為建模。
如上所述，不能有效地監視跨這些對等點的網際網路流量的大部分，而只是有效地監視這種流量對跨這些對等點的a節點之間的asn間的跳的隨時間的影響。獲得越多的性能度量，越能夠更好地預測這樣的asn間的跳所需的時間，該時間然後被量化為相對擁塞級別(例如，與通常不太擁擠的asn內的跳相比，儘管如此，在本實施例中也進行監視)。
由於對等點的擁塞級別是如此動態，所以這種預測只能在短時間內準確。但是，考慮到這種分析是連續執行的，並且可能針對下一個1秒的視頻段改變，所以預測在長時間內準確並不重要。
在一個實施例中，深度映射器360基於非常粗略的信息(即，在獲得大量客戶端性能度量之前)初始量化asn對等點。例如，如果asn具有1000個對等點，則可以假設它是一個骨幹網，該骨幹網可能比具有6個對等點的另一asn快得多。隨著獲得更多的客戶端性能度量，這些asn對等點擁塞級別將變得更加準確。在另一個實施例中，部署多個「學習節點」以「跳轉開始」新的頻道。這些學習節點是不查看視頻的僅發送節點，而是僅部署來快速提供客戶端性能信息，使得深度映射器360可以比該情況本來的更早開始做出更準確的預測。
此外，在一個實施例中，深度映射器360還考慮asn內擁塞，因為這可以暗示例如asn內對附加a節點的需求，並因此對創建附加的群組覆蓋網絡的需求。例如，如果asn內的許多客戶端節點隨時間逐漸花費更長的時間來獲得視頻段，則深度映射器360標記該asn以指示需要附加的a節點，而覆蓋網絡創建器350可以將一個或多個b∶a節點「提升」為a節點，導致虛擬數據幹線覆蓋網絡的部分重新配置，並最終要求asn內的新的群組覆蓋網絡。在另一實施例中，深度映射器360在每個asn內應用深度學習技術，並且協助覆蓋網絡創建器350生成asn內群組覆蓋網絡。
因此，覆蓋網絡創建器350和深度映射器360一起工作，以建立客戶端節點之間的路由(經由覆蓋網絡100)，以最小化跨不必要的遠距離路由(即跨多個asn對等點)對視頻段的中繼，其中，該路由基於網際網路的底層架構(asn互連地圖)和覆蓋在該架構之上的客戶端節點的asn位置。此外，覆蓋網絡創建器350和深度映射器360還一起工作，以持續地實時分析由客戶端設備200獲得的客戶端性能度量，並在這些指標揭示出重大問題(通常是由於asn對等點處的擁塞造成)的情況下動態地重新配置覆蓋網絡100。因此，可以監視網際網路的qos波動性，並且可以通過在問題「發生之前」圍繞這些問題動態地重新路由(基於由深度映射器360生成的所預測的擁塞級別)，最大限度地減少對擁塞的客戶端節點(特別是在asn對等點)的影響。
在一個實施例中，虛擬廣播伺服器300包括用於識別趨勢視頻事件(「潑濺」)的潑濺提取器390搜尋引擎，並且使得用戶能夠在這些事件的域之間進行搜索且將所期望的潑濺結果的流作為視頻頻道從poi內容伺服器380立即進行流傳輸(其中，這樣的頻道在虛擬廣播伺服器300處本來不可用)。
在一個實施例中，潑濺提取器390從多個新聞源連續地收集數據，例如，通過api到twitter、rssfeeds、reddit以及數以萬計的在線雜誌。平均而言，在這些來源中每小時都會顯露出數千個不同的「當前事件」。潑濺提取器390採用新穎的自動化方法來識別這種趨勢事件(潑濺)，並定位並提取可經由poi內容伺服器380獲得和流傳輸的相關視頻。
潑濺提取器390識別「與規範的偏離」，以檢測潑濺。例如，通過在新聞源的領域中採用例如標準的列文斯特比較算法開發了基線(無需規範化數據)。平均來說，除非具體話題的確是趨勢，或直到具體話題的確是趨勢為止，一些來源才會在短時間內討論相同的「話題」(即關鍵字的集合)。在這一點上(例如，當15個或更多來源在短時間內討論同一話題時)，該話題被識別為偏離(deviation)，並因此被識別為「潑濺」。
潑濺提取器390然後從這些來源中提取「最重要的」關鍵字(例如，在一個實施例中為40個關鍵字)，在一個實施例中，通過採用標準神經網絡技術從「潑濺相關」文章中學習和預測不同的關鍵字。然後將這些關鍵詞分類(例如，作為新聞，體育等)並按頻率排序。
潑濺提取器390然後使用這些關鍵字搜索社交媒體以獲得與每個潑濺有關的視頻，並對與這些潛在的潑濺視頻頻道相關聯的相關文本進行編索引。用戶可以搜索該索引，或者只是瀏覽潑濺視頻事件的類別。在選擇結果(無論搜索的或瀏覽的)之後，用戶可以立即流傳輸所期望的視頻。在一個實施例中，用戶簡單地連結到視頻的當前來源，而在另一實施例中，經由虛擬廣播伺服器300獲得視頻，並從poi內容伺服器380流傳輸該視頻(例如，如果大量的並發用戶請求相同的潑濺視頻頻道，這是有用的)。
動態視頻流傳輸處理
已經討論了本發明的虛擬廣播系統的關鍵客戶端側和伺服器側組件，圖4的流程圖400示出了這些組件如何動態交互。換言之，流程圖400示出了由這些組件實現的本發明的動態流傳輸處理的一個實施例。應當注意，由於該過程的大部分是事件驅動的並且不是線性的，因此流程圖400從客戶端側和伺服器側功能之間的交互的角度示出了步驟。
步驟401示出了上載器280(且在上面描述)中執行的處理，其中視頻事件由客戶端節點(例如，客戶端設備200上的智能相機219)捕捉到或者數字地生成或者從外部來源獲得。在任何情況下，客戶端(例如，客戶端設備200)然後將該視頻事件的視頻段(無論是實時捕捉的還是預先錄製的)流傳輸給虛擬廣播伺服器300。
無論視頻事件是從客戶端還是從更傳統的cdn(以及它們是被預先錄製還是實況流傳輸的)獲得的，虛擬廣播伺服器300在步驟410中準備每個視頻頻道以進行從poi內容伺服器380的實況流傳輸，如上所討論的。此時，在一個實施例中，頻道網頁被生成並最終由潛在的客戶端節點遇到。當客戶端設備200的用戶點擊所期望的頻道時，連接請求將與客戶端功能(諸如作業系統的類型、瀏覽器、連接等)一起發送給信令伺服器330。備選地，客戶端設備200的用戶可以遇到趨勢性的潑濺視頻事件(如上所述)，並且選擇該視頻事件(在步驟410中)，以用於從poi內容伺服器380作為視頻頻道來流傳輸。
在步驟412中，信令伺服器330驗證客戶端與該頻道的連接性(例如，通過採用stun322協議來識別客戶端的公共ip地址)，然後通過客戶端上可能存在的任何nat防火牆建立網絡套接字326連接，並且稍後向其他客戶端節點提供該公共ip地址以將視頻段中繼給該客戶端。信令伺服器330然後將控制轉交給覆蓋網絡創建器350，覆蓋網絡創建器350將(尚未分類)的客戶端作為節點添加到覆蓋網絡100上，從該覆蓋網絡100，初始視頻段將被推送給客戶端(在步驟414中)，使得在步驟415中，用戶可以立即開始觀看視頻頻道。
信令伺服器330然後在步驟416中將客戶端設備200分類為a、b∶a、b或c節點，並且在步驟430中，使用覆蓋網絡創建器350和深度映射器360二者來動態地重新配置asn間(虛擬數據幹線)和asn內(群組)覆蓋網絡100，以將客戶端設備200併入網絡拓撲中。然後，信令伺服器330向其他客戶端節點提供相關的路由信息，以開始將視頻段中繼給客戶端設備200。
poi內容伺服器380然後在步驟435中，響應來自附近節點(通常為a節點)的http請求，作為沿著當前(重新配置的)覆蓋網絡100的視頻頻道的起點，將視頻段流傳輸給那些節點，其中每個視頻段被逐節點地中繼，直到它被中繼給客戶端設備200並被其觀看。
雖然客戶端設備200正在接收塊並進行彙編(compile)，但是在步驟450中，為了觀看頻道的每個視頻段(並且潛在地還在步驟440中將塊中繼給其他指定的客戶端節點)，在步驟425中，它還監視其性能(如上面關於性能監視器240所討論的)，並且向信令伺服器330提供客戶端性能度量。此外，當請求每個視頻段時，由於視頻段被沿著覆蓋網絡100推送給客戶端設備200(如上所述)，在步驟455中(在一個實施例中，由接收機250中的客戶端javascript代碼)攔截這些請求。從步驟455到步驟425的箭頭僅僅表示步驟425中的監視處理是與視頻段的接收、查看和中繼同時進行的連續操作。
如上所述，即使視頻段被從其他客戶端節點推送給客戶端設備200，客戶端設備200也周期性地向poi內容伺服器380發起請求清單文件(例如，包含接下來的8個視頻段的位置)的http請求。偶爾，如果視頻段沒有及時到達，則客戶端設備200將直接向poi內容伺服器380請求該視頻段來作為回退位置。此外，有時，根據自適應流傳輸224標準，客戶端設備200還可以聯繫poi內容伺服器380以請求修改的比特速率(例如，一旦檢測到其性能級別的改變)，以用於後續視頻段。然而，如上所述，接收機250可以更早地檢測到這種需要，並且聯繫虛擬廣播伺服器300來通過覆蓋網絡100使這種改變生效，指示饋送客戶端節點自動將更低或更高解析度的視頻段推送給客戶端設備200(即不響應其請求)。
在步驟452中，poi內容伺服器380響應這樣的http請求，並將所請求的清單文件和回退視頻段傳送給客戶端設備200。如上所述，比特速率的改變通過覆蓋網絡100(並且在步驟430中)來解決，導致更低或更高解析度的視頻段被推送給客戶端設備200。
步驟454包括由性能跟蹤器340、覆蓋網絡創建器350和深度映射器360執行的連續過程(在一個實施例中，針對每個視頻段執行，並且在上面詳細描述)。在該步驟454中，持續地更新客戶端性能信息，並且如果需要，在步驟430(如從步驟454到步驟430的箭頭所指示的)，覆蓋網絡100被動態地重新配置，並且新的路由信息被提供給相關的中繼節點通過信令伺服器330。
最後，在步驟460中，潑濺提取器390連續地識別趨勢性的潑濺視頻事件，然後如上所述地流傳輸以便立即觀看，這些潑濺視頻事件可被客戶端設備200的用戶瀏覽或搜索。
這裡參照附圖所示的具體實施例描述了本發明。應當理解，根據本公開，本領域技術人員可以在本發明的範圍內設想和實現本文公開的概念的附加實施例。