基于DVB-C的流媒體廣播系統實驗研究
1 引言
基于DVB-C的數據廣播在共享多媒體等海量數據方面具有明顯的優勢,可解決網絡上傳輸海量流媒體信息資源引起的網絡阻塞,是一種低成本接收和可提供優質服務的優秀信息共享結構。因此,基于DVB-C數據廣播網的流媒體技術是具有潛力的技術。
為此,本文介紹了一種搭建在實驗室的流媒體廣播系統,可用于DVB-C有線電視廣播網平臺,為現有DVB-C數字有線電視系統開展流媒體業務提供了一種由發送端到接收端的解決方案。
2 流媒體傳輸技術方案
流媒體的傳輸涉及到兩方面的技術:其一,服務器端與客戶端的通信技術,包括多媒體數據的傳輸、命令控制等;其二,客戶端對收到的多媒體流實時解碼播放的技術。
本文中,對多媒體流的解碼播放使用DirectShow技術,它將流媒體處理劃分為若干個連續的步驟,包括音視頻數據的采集、傳輸、分離、合并、編碼、解碼和回放等。每個具體的流媒體處理過程可由其中的幾個步驟組成。利用其中濾波器處理一個或多個步驟,用不同的濾波器實現不同的功能。開發人員可創建自己的濾波器,也可用微軟或第三方提供的濾波器。應用程序連接若干個濾波器進行指定的流媒體處理。數據可在不同的濾波器間傳輸,傳輸方向一般是單向的。一個過濾器通過輸出針將特定的輸出送到下游過濾器的輸入針。傳輸的數據加有時間戳,用來同步音視頻數據的回放。
圖1為利用DirectShow開發流媒體程序的框圖。

在DirectShow中,濾波器分為3類。
1) 源濾波器:從數據源獲取原始數據。不同的源濾波器可處理一類或多類數據源,包括本地文件、網絡和數據采集卡等。
2) 變換濾波器:用來獲取、處理和傳送媒體數據,它包括分離視頻和音頻的切分過濾器、解壓視頻數據的視頻解碼過濾器、解壓音頻數據的音頻解碼過濾器。
3) 終端濾波器:對數據進行最后的處理,可顯示視頻、回放音頻、保存數據或者將數據發送到網絡等。
3 系統設計
3.1 系統總體設計
在DVB傳輸協議的基礎上,采用合適的硬件和軟件結構可構建一套數據廣播系統。圖2給出了在實驗室搭建的基于DVB-C的數據廣播系統平臺結構圖。

系統所用設備:北京藍拓撲的IP/DVB網關(BDG-10)和數據接收卡(BDR-10C);九州QAM調制器;普通PC機,其中服務器使用WIN XP操作系統;客戶機使用的WIN 2000操作系統;IP/DVB網關使用WIN 2000Server操作系統。
該系統同時具備本地文件廣播及流媒體廣播功能。服務器利用IP多播技術,將UDP數據包通過內部以太網傳送到IP/DVB網關,把輸入的IP數據打包成DVBTS碼流輸出,經過640AM調制器調制到一個特定的8MHz帶寬的模擬電視頻道上,在有線電視網上傳送,信號經過分支器進行衰減,客戶端的PC機使用DVB-C接收卡接收各類文件及流媒體數據。
根據流媒體系統的設計要求,整個基于DVB-C的流媒體廣播軟件系統由服務器數據廣播發送軟件系統和客戶端接收實時播放軟件系統組成。
3.2 服務器端軟件設計
實驗系統軟件設計采用面向對象的程序設計方法,藍拓撲接收卡提供了適用于Visual C++6.0的API接口函數,因此,軟件開發臺使用Visual C++提供的MFC編程平臺,發送接收使用Windows Socket技術,采用面向無連接的UDP協議來實現服務器端主動發送數據、用戶端被動接收數據。發送端選擇MPEG-1編碼格式的多媒體文件作為節目源。
其發送進程如圖3所示。

1) 初始化進程環境

2) 數據庫記錄集對象_RecordsetPtrm_pRecordset首先移動到記錄集中的第一條記錄處m_pRecordset.Movefirst();
3) 讀取數據庫獲得文件路徑(數據庫第三欄)m_p Recordset->GetCollect(“位置”),用函數CFile::Open打開待發送的文件;
4) 啟動文件發送線程(一個函數循環),用函數CFile::read順序讀取文件數據(74 368 bit)到緩沖區,緩沖區定義為
#define MPEG1_PACK 9296
cbar* pBuf = new char[MPEG1_PACK]
用CSocket::SendTo函數將緩沖區數據封裝成UDP包并發送到網關,等待30 ms后繼續此循環,直至文件發送完畢;
5) 將記錄集對象指針移動到下一條記錄處,發送下一個文件,程序執行3),直至記錄集對象指針指到最后一條記錄處。
3.3 客戶端軟件設計
客戶端接收并解碼播放部分是系統的難點也是重點。客戶端解碼播放部分建立的DirectShow過濾器如圖4所示。除了源濾波器外,其他濾波器由DirectShow SDK中提供,但MPEG-1切分過濾器只能工作在拉模式(切分過濾器向源過濾器發送數據請求,源過濾器發送數據來回應請求)下,因此,Source Filter也設計成拉模式。

客戶端接收實時回放軟件系統所用的關鍵技術有:
1) 雙緩沖隊列技術
客戶端通過函數CSocket::ReceiveFrom循環接收服務器端發送的數據包,為減輕網絡抖動的影響,必須進行一定量的緩沖,才能交給DirectShow解碼處理,動態地一邊繼續從網絡接收數據,一邊將得到的數據進行解碼回放。因此,使用了雙緩沖隊列技術,封裝的CDataAdmin類實現對數據接收隊列的管理。
建立了兩個隊列:第一隊列是空閑的緩沖隊列Pool-List,用以接收存放數據包;另一個是尚未處理的數據緩沖隊列DataList,等待下游Filter的讀取。其代碼如下:

當客戶端接收到一個包的數據,從PoolList的頭部拿出一個緩沖塊,存放數據,然后將這個緩沖塊加入到DataList的尾部等待DirectShow的Filter讀取;從DataL-ist頭部拿出一個緩沖塊,DirectShow的Filter讀取緩沖塊內的數據,讀完后將緩沖塊加入到PoolList的尾部,等待再一次地接收數據。
2) 源過濾器的設計
流媒體數據傳輸技術決定了DirectShow Filter只能讀取緩沖中的各個包數據,由于DirectShow只提供了異步文件源過濾器和URL文件源過濾器,因此,自己必須設計源過濾器。如圖5所示。

在源過濾器的模塊結構中,過濾器CMemStream是從DirectShow SDK中的基類CAsyncStream繼承而來,處理從第二隊列中讀取數據,主要是由重載的CMem-Stream::read函數完成。輸出CAsyrncOutPin實現了I-AsyncReader接口以支持異步操作。所使用的切分過濾器的輸入pin是拉模式,它從CAsyncOutputPin的IAsyn-cReader接口中索取數據。圖中所有的數據請求都是由異步I/O操作類CAsyncIo來處理,而CAyncIo的核心是請求對列處理線程,它不停地從請求隊列中取數據請求并處理,實現異步數據請求操作。
總體數據流向為:在建立源濾波器CMemReader時,CMemReader會建立一個CAyncIo對象且CAsyncIo在合適啟動一個請求丟隊列處理線程,然后開始以下的處理流程:1)MPEG-1切分過濾器向CAyncOutputPin提出數據請求;2) CAsyncOutputPin將該請求加以包裝并加入到CAsyncIo的請求隊列中,由處理線程來處理;3)處理線程通過內部流類CMemStream訪問緩沖區,讀取數據并通過CAyncOutputPin發給MPEG-1切分過濾器。實際應用時,使用了DirectShow SDK提供的基類CAyncIo和CAyncOutputPin,CMemReader是從DirectShow SDK中的基類CAsyncReader繼承而來,這一切簡化了程序設計。
4 實驗結果分析
實驗完成了單路多媒體數據的廣播流式發送與接收并實時播放。利用丟包率與網絡帶寬等信息來檢測網絡狀態與確定發送速率。
1) 丟包的檢測
在單播環境中,本文采用的檢測方法為:發送端在發送固定數量的MPEG-1格式文件的同時,發送固定頻率的空UDP包;接收端通過檢查能接收到的包數目來檢測包丟失情況。本服務器端發送4 495個數據包的MPEG-1格式文件,每個數據包9 296 byte,同時服務器端以2.1 Mbit/s的速率發送空的UDP測試包,接收端能收到的平均包數日為3 701,丟包率為17.7%。這主要是由網絡擁塞與網絡線路衰減引起的。
丟包情況下接收端有馬賽克現象,但是現象影響輕微,用戶可觀看流暢的流媒體節目,并能把收到的節目存入文件。這表明在實驗中,流媒體廣播能成功接收。
2) 網絡帶寬
DVB-C平臺中調制器參數設置為:64QAM調制;網關最大傳輸速率為32 Mbit/s,可復用多路服務器的數據在8 MHz的模擬頻道上進行傳輸,例如文件服務器等。流媒體數據的占用帶寬情況可在IP/DVB網關中觀測到,實際占的最大帶寬可等效于3.17 Mbit/s,網關可復用多路獨立的流媒體服務器的同時并行發送。
因此,DVB-C廣播平臺擁有較高的傳輸速率,在單向傳輸大容量多媒體數據時比因特網更具有優勢,可有效緩解因特網中的信息擁塞問題。
相關推薦
-
| 2009-10-26
-
| 2007-02-09
-
| 2007-03-15
-
| 2010-02-10
-
-
-
| 2012-07-31
-
| 2006-01-13
-
| 2006-07-14
-
-
-
-
-
-
| 2007-02-09
-
| 2007-04-19
-
| 2010-01-18
-
| 2010-01-18
-
| 2012-07-31
-
| 2007-03-30
-
| 2014-12-31
-
-
| 2005-12-30
-
| 2006-09-17
-
-
| 2005-12-08
-
| 2009-07-06
-
| 2009-10-15
-
| 2010-01-18


評論