[解析]流媒體客戶端的結(jié)構(gòu)與原理淺析

[解析]流媒體客戶端的結(jié)構(gòu)與原理淺析
中國投影網(wǎng)資訊 [2005-8-27 9:20:12] 編輯:伊琳

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

     一、系統(tǒng)結(jié)構(gòu)

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

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

     RTSP會話控制層由播放器主線程來完成，負責(zé)RTSP相關(guān)控制指令的傳送與接收分析。RTP數(shù)據(jù)傳輸層和解碼層分別由從主線程產(chǎn)生的接收和解碼線程來完成，接收和解碼線程對應(yīng)視頻數(shù)據(jù)和音頻數(shù)據(jù)又各自分別獨立為兩個不同的線程處理數(shù)據(jù)的接收和解碼任務(wù)。顯示播放層同樣也實現(xiàn)視頻、音頻兩個獨立的播放任務(wù)。

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

    二、工作原理

    1. RTSP會話連接

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

    2. 解碼前的RTP數(shù)據(jù)處理

    RTP[3]傳輸通�；趥鬏斝瘦^高數(shù)據(jù)可靠性較低的UDP協(xié)議，是一個針對實時數(shù)據(jù)的傳輸協(xié)議。在UDP數(shù)據(jù)包之前增加了一個RTP包頭，其中包含了一些可以較好保證流數(shù)據(jù)連續(xù)性實時性的信息，如序列號、時間戳等。序列號可以保證到達客戶端的RTP包的連續(xù)，而時間戳可以同步音視頻包。

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

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

從接收到解碼，音視頻數(shù)據(jù)都是在互為獨立的線程中處理，因此可能會由于網(wǎng)絡(luò)或終端環(huán)境因素而失去同步。

     3. 解碼后數(shù)據(jù)處理

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

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

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

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

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

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

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

     4. 音視頻同步

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

     5. 音視頻播放

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

     三、結(jié)束語

     流媒體技術(shù)是多媒體數(shù)據(jù)在互聯(lián)網(wǎng)上傳輸很有前途應(yīng)用最廣泛的技術(shù)，客戶端播放器作為其中一個重要的組成部分，其性能的好壞直接影響到用戶的服務(wù)質(zhì)量。在客戶端中，音視頻數(shù)據(jù)的處理從接收到解碼都是在相互獨立的線程中，然后利用數(shù)據(jù)的時間戳進行同步保護�？蛻舳说耐ㄐ排c傳輸需要遵從RTP和RTSP，這是其支持流媒體播放的一個重要標準。

更多相關(guān)：

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

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