一種低延時網絡自適應直播系統的制作方法
【技術領域】
[0001] 本發明涉及直播技術領域，具體是一種低延時網絡自適應直播系統。
【背景技術】
[0002] 直播系統可以應用戶的要求把活動現場的音頻或視頻信號經壓縮后，傳送到服務 器上，在網絡上供廣大觀眾或授權特定人群收聽或收看。現有的直播系統存在以下幾個問 題：1)通常只對數據流進行分發或轉發，不進行流的篩選，做透明傳輸，無法獲取流中的數 據；2)大多采用集中式管理，當幾個流媒體服務器同時運行時，每個服務器通常只服務某 區域或某部分特定用戶，數據源對用戶是隔離的。服務器間少有數據流通，當數據源在其它 服務器上時，用戶無法觀看數據；3)通常采用同步方式將數據傳到用戶，效率低，延遲大； 4)通常手動部署和升級，需要專業人員進行控制；5)沒有網絡擁塞控制。
【發明內容】
[0003]本發明的目的在于提供一種精準、實時、高效的低延時網絡自適應直播系統，用于 遠程醫療及醫學會議時中轉攝像頭的視頻和音頻數據到用戶端。
[0004] 為實現上述目的，本發明提供如下技術方案：
[0005]低延時網絡自適應直播系統，包括攝像頭、服務器、用戶端；所述的攝像頭和服務 器的個數至少為一個，每個服務器連接一個以上的攝像頭，攝像頭采集數據流，并將采集到 的數據流推送到服務器，服務器利用通道記錄數據流與攝像頭之間的關系；當用戶端通過 通道向某一服務器獲取數據流時，如果該服務器中有這個通道，服務器直接將該通道所對 應的攝像頭采集的數據流推送到用戶端進行顯示，如果該服務器中沒有這個通道，服務器 向其他服務器獲取，并將該通道對應的數據流轉發回用戶端進行顯示。
[0006]所述的攝像頭采集的數據流的類型包括音頻和視頻，其中視頻類型的數據流采用 的是FLV格式。
[0007]所述的數據流與通道一一對應，可支持直播和錄像兩種功能。
[0008]所述的服務器在接收數據流時，對攝像頭傳輸的FLV格式的數據流進行解析，將 不同類型的數據流分別緩存到不同的隊列，并區分關鍵幀和普通幀，當網絡狀況較差時，根 據幀的類型丟棄部分普通幀，以減小網絡負擔，保證數據流的安全可靠傳輸。
[0009]所述的服務器通過對觀看者隊列的大小進行限制而實現網絡擁塞預知功能，如果 觀看者隊列上溢的話，則丟棄隊列中的部分普通幀，并記錄丟幀情況。
[0010] 所述的系統采用分布式集群，能支持大量用戶端的并發訪問。
[0011] 所述的系統采用的是腳本控制方式。
[0012] 所述的系統的實現方法為：
[0013] (1)開始：服務器創建一線程池，啟動事件循環；
[0014] (2)服務器監聽網絡請求，當有攝像頭發出推送請求時，進入步驟（3);當有觀看 者通過用戶端從某一通道發出直播請求時，進入步驟（4);
[0015] (3)服務器解析攝像頭的地址，維護頻道列表，建立頻道與線程ID的映射關系；月艮 務器接收FLV格式的數據流，解析數據流中的tags，進行緩存；
[0016] (4)服務器調取所述的通道對應的數據流至用戶端，進行實時直播；服務器解析 觀看者的地址后，判斷直播頻道是否匹配，如果不匹配，服務器模擬用戶的地址請求，向其 他服務器發送請求；如果匹配，服務器根據直播頻道編號而調度工作線程，讀取緩存的數據 流，將數據流保存至觀看者隊列，并實時推送給觀看者，觀看者通過用戶端實時觀看。
[0017] 與現有技術相比，本發明的有益效果是：
[0018] 本系統在接收數據流時，對FLV格式的數據流流進行解析，對音頻、視頻及其它類 型的數據流進行分類處理，將關鍵幀與普通幀區分處理，使用戶接收到的流信息更加精準。
[0019] 本系統采用回源機制，用通道記錄數據流與攝像頭之間的關系。連接到系統的用 戶通過通道發出獲取數據流的請求，系統會依據用戶運營商，訪問直播地址及直播源所在 網絡，當前各個服務器負載動態分配一個與用戶最近的服務器。由服務器從源端直接獲取 或向其他服務器請求直播源數據，再傳送到用戶端。因此可以支持多路通道及大量用戶并 發訪問。
[0020] 本系統將數據流與通道對應，可以支持直播和錄像兩種功能。
[0021] 本系統將接收數據流和推送數據流的操作分離，異步實現轉發過程，同時對收到 的數據流進行緩存，并根據推送數據流的速度判斷網絡狀況，動態調節緩存隊列大小，傳輸 效率高，延遲小。
[0022] 本系統使用腳本實現交互式自動化升級，無需專業人員參與。
【附圖說明】
[0023] 圖1是本系統的實現流程圖；
[0024] 圖2是FLV文件的結構圖；
[0025] 圖3是FLV音頻Tag的結構圖；
[0026] 圖4是FLV視頻Tag的結構圖；
[0027] 圖 5 是FLVScriptTag的結構圖；
[0028] 圖6是本系統的數據流的接收與推送流程圖；
[0029] 圖7是本系統的服務器的工作線程機制圖。
【具體實施方式】
[0030] 下面將結合本發明實施例，對本發明實施例中的技術方案進行清楚、完整地描述， 顯然，所描述的實施例僅僅是本發明一部分實施例，而不是全部的實施例。基于本發明中的 實施例，本領域普通技術人員在沒有做出創造性勞動前提下所獲得的所有其他實施例，都 屬于本發明保護的范圍。
[0031] 請參閱圖1，本發明實施例中，一種低延時網絡自適應直播系統，包括攝像頭、月艮 務器、用戶端；所述的攝像頭和服務器的個數至少為一個，每個服務器連接一個以上的攝像 頭，攝像頭采集數據流，并將采集到的數據流推送到服務器，服務器利用通道記錄數據流與 攝像頭之間的關系；當用戶端通過通道向某一服務器獲取數據流時，如果該服務器中有這 個通道，服務器直接將該通道所對應的攝像頭采集的數據流推送到用戶端進行顯示，如果 該服務器中沒有這個通道，服務器向其他服務器獲取，并將該通道對應的數據流轉發回用 戶端進行顯示。
[0032] 攝像頭采集的數據流的類型包括音頻和視頻，其中視頻類型的采用FLV格式。
[0033]FLV全稱是FlashVideo,是互聯網上使用極為廣泛的視頻封裝格式。總體上看， FLV包括文件頭（FileHeader)和文件體（FileBody)兩部分，其中文件體由一系列的Tag 組成，結構如圖2所示。其中，每個Tag前面還包含了PreviousTagSize字段，表示前面 一個Tag的大小。Tag的類型可以是視頻、音頻和Script，每個Tag只能包含以上三種類型 的數據中的一種。下表展示了FLV文件的詳細結構。
[0034]
[0036] 1.FLVAudioTag
[0037] 音頻Tag開始的第1個字節包含了音頻數據的參數信息，從第2個字節開始為音 頻數據流。結構如圖3所示。
[0038] 第1個字節的前4位的數值表示了音頻編碼類型
[0039]
[0040] 第1個字節的第5-6位的數值表示音頻采樣率 [0041 ]
[0042] 第1個字節的第7位表示音頻采樣精度
[0043]
[0044] 第1個字節的第8位表示音頻類型
[0045]
[0046] 2.FLVVideoTag
[0047] 視頻Tag也用開始的第1個字節包含視頻數據的參數信息，從第2個字節為視頻 數據流，其結構如圖4所示。
[0048] 第1個字節的前4位的數值表示幀類型
[0049]
[0050] 第1個字節的后4位的數值表示視頻編碼類型
[0051]
[0052] 3.FLVScriptTag
[0053] 該類型Tag又通常被稱為Metadata Tag，會放一些關于FLV視頻和音頻的元數據 信息如：duration、width、height等。通常該類型Tag會跟在File Header后面作為第一 個Tag出現，而且只有一個。結構如圖5所示：
[0054] 第一個AMF包：第1個字節表示AMF包類型，一般總是0x02,表示字符串。第2-3 個字節為UI16類型值，標識字符串的長度，一般總是OxOOOA( "onMetaData"長度）。后面 字節為具體的字符串，一般總為 "onMetaData"（6F，6E，4D，65, 74, 61，44, 61，74, 61)。
[0055] 第二個AMF包：第1個字節表示AMF包類型，一般總是0x08,表示數組。第2-5個 字節為UI32類型值，表示數組元素的個數。后面即為各數組元素的封裝，數組元素為元素 名稱和值組成的對。常見的數組元素：
[0056]
[0057] 低延時網絡自適應直播系統對攝像頭傳輸的FLV格式數據流