[解析]流媒體客戶端的結構與原理淺析

[解析]流媒體客戶端的結構與原理淺析
中國投影網資訊 [2005-8-27 9:20:12] 編輯:伊琳

     流媒體是一種在網絡上在線播放多媒體的技術。由于其邊下載邊播放的特性，縮短了用戶初始等待的延遲，但其數據也需要采用流式傳輸，具有較高的實時需求，因此比起一般的本地播放處理更為復雜。客戶端是流媒體系統中一個基本的組成部分，一般是一個具有網絡通信功能的播放器，比較著名的具有流媒體功能的播放器有realplayer、Windows media player等。這里以在Windows平臺上自主開發的一套客戶端播放器為實例，介紹流媒體客戶端的系統結構和工作原理。

     一、系統結構

     根據工作平臺的不同，客戶端的形式也有多種，除了PC機，還可以運行在機頂盒或無線便攜式設備上。但是客戶端的工作流程卻都是相似，即從網絡中接收從流服務器傳輸過來的各類媒體數據流，存入一個緩沖隊列，然后對其中的每一幀數據調用各類解碼器重建成原始的數據格式，最后經同步后在設備上播放出來。

     從功能層次上看，播放器主模塊可以分為四個層次：RTSP會話控制層、RTP數據傳輸層、解碼層和顯示播放層（如圖1所示）。播放器與服務器之間的通信主要是由位于應用層的RTSP協議和位于傳輸層的RTP 協議（Real-time Transport Protocol）來實現的。

     RTSP會話控制層由播放器主線程來完成，負責RTSP相關控制指令的傳送與接收分析。RTP數據傳輸層和解碼層分別由從主線程產生的接收和解碼線程來完成，接收和解碼線程對應視頻數據和音頻數據又各自分別獨立為兩個不同的線程處理數據的接收和解碼任務。顯示播放層同樣也實現視頻、音頻兩個獨立的播放任務。

     對于各層之間的信息交互，首先由RTSP會話控制層向流媒體服務器提出請求并建立連接，然后RTP數據傳輸層負責對網絡上傳送過來的實時視頻、音頻數據進行預處理，主要是統計相關數據信息并依照RTP包頭在緩沖隊列中進行排序。根據RTP數據包頭時戳信息，按時送達到解碼層進行解碼。解碼線程選擇匹配的解碼器進行解碼，并最終在顯示播放層完成最終的播放。

    二、工作原理

    1. RTSP會話連接

    RTSP[2]是基于TCP協議的一個實時流控制協議。通過此協議，可以為服務器和客戶端建立會話控制連接，為多媒體流提供遠程控制功能，諸如播放、暫停、跳躍、停止等。因此對于客戶端應該首先連接服務器端的RTSP端口。建立RTSP連接后，客戶端發送DESCRIBE方法給服務器，其中包含了點播文件的URL。如果存在認證步驟，服務器就會返回一個錯誤碼，接著，客戶端會將用戶輸入的用戶名和密碼包含進RTSP包并再次發送DESCRIBE。服務器收到后會傳送媒體描述文件SDP（符合RFC2327標準）到客戶端播放器。客戶端讀取SDP描述文件來配置音頻、視頻解碼同步信息，例如：文件名、網絡類型、RTP數據傳輸通道端口號、編碼類型、采樣率等。在配置好音視頻相關信息后，客戶端發送SETUP方法給服務器，配置相關的傳輸網絡協議，傳輸方式和端口等信息。最后在創建好接收解碼線程后，客戶端發送PLAY方法，通知服務器往本地RTP接收端口發送音視頻數據。會話結束后，客戶端發送TEARDOWN到服務器斷開連接。此外，在會話期間，客戶端可以通過改變PLAY指令的參數，以及PAUSE指令實現播放暫停跳躍等VCR功能。圖2中的TEST，RESEND和ECHO指令是我們為智能流服務增加的幾個RTSP指令。

    2. 解碼前的RTP數據處理

    RTP[3]傳輸通常基于傳輸效率較高數據可靠性較低的UDP協議，是一個針對實時數據的傳輸協議。在UDP數據包之前增加了一個RTP包頭，其中包含了一些可以較好保證流數據連續性實時性的信息，如序列號、時間戳等。序列號可以保證到達客戶端的RTP包的連續，而時間戳可以同步音視頻包。

在RTSP的SETUP包中，客戶端會通知服務器本地RTP接收端口。因此在創建接收線程時，首先創建本地UDP的socket端口并綁定。然后循環等待接收從服務器傳來的RTP音視頻數據包，并將接收到數據按序列號順序插入到一個緩沖隊列中。初始緩沖長度可以由用戶設定。新的數據包根據其序列號插入到隊列中正確的位置。

一旦緩沖增加到初始閾值，客戶端將啟動解碼線程，開始循環讀取緩沖的頭部節點數據。每次客戶端將讀取緩沖中具有相同時間戳的數據作為一個整體送入解碼器中。由于視頻的一幀數據被拆分成幾個時間戳相同的RTP數據包，而音頻沒有這樣處理，每個RTP包的時間戳都不一樣。因此，每次送入解碼器的是視頻的一幀或是音頻的一個RTP包單元的數據，具體如圖3所示。

從接收到解碼，音視頻數據都是在互為獨立的線程中處理，因此可能會由于網絡或終端環境因素而失去同步。

     3. 解碼后數據處理

     解碼器每次解碼一幀視頻或是一個音頻包（后面統稱為一個數據單元），由于被解碼后的數據并不一定就馬上需要被播放，為了保證安全性，從將一幀解碼到將此幀顯示出來，中間可以經過一段緩沖存儲過程。

     可以設計一個緩存，包含了一些長度（視頻是16，音頻是32）固定的數組，分別用來存儲解碼后數據內容以及播放時間信息和當前填充狀態。解碼后的每一個數據單元被存入緩存，然后到播放時間時再從緩存中取出相應的數據單元。每取出一個數據單元則將新的一個數據單元填入被取出數據留出的空間。如此可以循環使用該固定長度的緩存空間。

     這段緩存對于視頻，每一幀已解碼的數據被填入到同一個數組單元之中；對于音頻，每一個RTP包單元的數據解碼之后被填入到一個數組單元中。同時建立了兩個索引，一個用于填入數據，一個用于取出數據。

     以視頻為例，初始時首先連續解碼16幀的數據，將緩沖數組填滿，如圖4（a）所示：1表示已有數據填入，0表示數據已經取出。

     當第15組數據填完后，填值索引重新指向第0個數組。然后播放器繼續解下一幀。但是第0組里已經有數據，所以無法再往第0組填入數據，此時填值操作進行等待。此時取值索引初始時也指向第0組數據，當當前時間等于第0組的播放時間時，開始取出并播放第0組的解碼數據，取值索引移到第一組，此時第0組無數據。

     第0組數據播放之后，將重新喚醒解碼線程，將已解出的下一幀數據填入到第0組之中，填值索引也移至第1組。然后播放器繼續解下一幀，但是第一組里數據尚未被取出顯示，所以無法填入新數據，解碼線程又開始等待，所示。如此循環下去，即完成了解碼到顯示之間的工作。

     對于音頻，不同的在于，每次播放將從緩存中取出固定長度或采樣點數的音頻數據。

     4. 音視頻同步

     前面曾提到，解碼到緩存中的音視頻數據由于不相關性是存在不同步的可能的，這樣在播放時會破壞服務質量，因此需要在播放前取出緩存中數據時對音視頻進行重同步。同步機制采用的是一個以系統時鐘為標準的計時循環。由于音頻對播放速率的均勻性要求更嚴，因此音頻的播放是根據其本身的幀率按一定的速率不斷的取出數據進行播放的。視頻則是根據計時器所更新的系統時鐘來確定是否播放，也就是說，當系統時鐘超過下一幀視頻的播放時間后，該視頻將被播放。系統時鐘的更新以音頻為基準。如果視頻失去同步，比如過分落后于當前系統時鐘，則會選擇跳幀來盡快趕上計時器時間；如果超過當前系統時鐘過多，則會暫時等待計時器計時增加。同樣，音頻出現意外情況時，也會作類似的處理。這樣，在以上機制的保證下，音視頻能夠始終按照一定的基準達到同步，并且能夠抵制外界變化對同步造成的影響。

     5. 音視頻播放

     音視頻媒體的播放可以調用DirectShow接口實現，分別使用DirectDraw和DirectSound通過驅動系統硬件設備來播放音視頻數據。DirectShow技術在音視頻采集，視頻聊天，視頻點播，視頻疊加，媒體播放等領域都有相當成熟的應用。在程序啟動時，需要先初始化音視頻的一些播放配置信息。如果是視頻，在解碼后如果到達某一幀的播放期限，則經過同步檢測后將數據內容作為參數調用函數進行顯示。音頻則是在初始化后啟動一個播放線程，在這個線程中存在一個循環，不斷讀取緩存中的音頻數據，然后進行播放。

     三、結束語

     流媒體技術是多媒體數據在互聯網上傳輸很有前途應用最廣泛的技術，客戶端播放器作為其中一個重要的組成部分，其性能的好壞直接影響到用戶的服務質量。在客戶端中，音視頻數據的處理從接收到解碼都是在相互獨立的線程中，然后利用數據的時間戳進行同步保護。客戶端的通信與傳輸需要遵從RTP和RTSP，這是其支持流媒體播放的一個重要標準。

更多相關：

文章來源:中國多媒體視訊

【推薦給朋友】【投稿建議】【加入收藏夾】【設為首頁】【大中小】【打印】【關閉】【評論】【頂部】