流媒體用戶端的結構與原理淺析

流媒體是一種在網路上線上播放多媒體的技術。由於其邊下載邊播放的特性，縮短了使用者初始等待的延遲，但其資料也需要採用串流，具有較高的即時需求，因此比起一般的本地播放處理更為複雜。用戶端是流媒體系統中一個基本的組成部分，一般是一個具有網路通訊功能的播放器，比較著名的具有流媒體功能的播放器有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技術在音視頻採集，視訊交談，ApsaraVideo for VOD，視頻疊加，媒體播放等領域都有相當成熟的應用。在程式啟動時，需要先初始化音視頻的一些播放配置資訊。如果是視頻，在解碼後如果到達某一幀的播放期限，則經過同步檢測後將資料內容作為參數調用函數進行顯示。音頻則是在初始化後啟動一個播放線程，在這個線程中存在一個迴圈，不斷讀取緩衝中的音頻資料，然後進行播放。

     三、結束語

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