1 引言

　　隨著IT 的發(fā)展，互聯(lián)網(wǎng)已進入千家萬戶，人們希望通過互聯(lián)網(wǎng)來收聽收看喜聞樂見的電視節(jié)目，流媒體（real-time media）技術的發(fā)展為人們提供了這種可能。電視作為典型的多媒體以其豐富的節(jié)目內容更加充實了互聯(lián)網(wǎng)本身，電視和互聯(lián)網(wǎng)的結合，將逐漸成為發(fā)展趨勢，網(wǎng)絡電視應運而生。網(wǎng)絡電視，也叫IPTV，是利用寬帶互聯(lián)網(wǎng)的基礎設施，以家用電視機作為主要終端，通過互聯(lián)網(wǎng)協(xié)議（IP）來提供包括電視節(jié)目在內的多種數(shù)字媒體服務及其增值業(yè)務的技術。IPTV最大的優(yōu)勢在于“互動性”和“按需觀看”，徹底改變了傳統(tǒng)電視單向廣播的特點。IPTV現(xiàn)在支持直播電視以及基于IP網(wǎng)絡的視頻點播業(yè)務。網(wǎng)絡電視已成為當今互聯(lián)網(wǎng)的亮點，越來越引起各級電視臺的重視。

　　2 網(wǎng)絡直播電視基本原理

　　網(wǎng)絡直播電視針對電視臺的現(xiàn)場節(jié)目（如娛樂晚會，體育比賽等），提供互聯(lián)網(wǎng)接入方式。直播節(jié)目在網(wǎng)絡傳輸上通常采用UDP組播方式，以達到節(jié)省網(wǎng)絡帶寬的目的。

　　圖1中Broadcaster負責對直播節(jié)目的模擬信號進行采集、編碼，并實時將編碼后的數(shù)字信號采用RTP/RTCP協(xié)議組播出去。對于每一個直播節(jié)目頻道，Broadcaster會生成一個SDP協(xié)議描述文件，描述該頻道組播數(shù)據(jù)流的相關參數(shù)，包括組播網(wǎng)絡地址、音視頻的采樣頻率等。Player是支持組播功能的流媒體播放器。接收直播電視節(jié)目時，Player首先得到該直播頻道的SDP文件，通過對SDP文件的解析，獲得該直播頻道的組播參數(shù)，加入組播組，接收組播數(shù)據(jù)流，收看直播節(jié)目。

　　3 延時續(xù)播電視設計與實現(xiàn)

　　通過網(wǎng)絡直播電視，用戶可以收看現(xiàn)場節(jié)目，突破了傳統(tǒng)電視節(jié)目的傳輸模式，但還無法發(fā)揮出網(wǎng)絡電視“互動性”和“按需觀看”的優(yōu)勢。

　　由于某些原因，用戶不能連續(xù)收看直播電視節(jié)目，比如在收看過程中需要接聽電話或者處理其他緊急事務。傳統(tǒng)的網(wǎng)絡直播電視不能針對這種情況對電視節(jié)目做相應的調整，用戶只能錯過部分直播電視節(jié)目。而延時續(xù)播電視在這種情況下，可以對直播電視節(jié)目做“暫?！碧幚恚斢脩籼幚硗晔种械氖虑楹笤龠M行“續(xù)播”操作就可以從剛才中斷的地方繼續(xù)收看直播電視節(jié)目。

　　3.1 基本原理

　　延時續(xù)播電視的實現(xiàn)需要流媒體服務器的參與，在Broadcaster組播直播節(jié)目的過程中，流媒體服務器不間斷地接收組播流，對組播流做緩沖處理。當用戶進行“延時續(xù)播”操作的時候，播放器從接收組播模式轉入延時續(xù)播模式，將延時的時間參數(shù)發(fā)送到流媒體服務器，接下來的電視節(jié)目數(shù)據(jù)由流媒體服務器從接收緩沖池中讀取，并發(fā)送至播放器。

　　3.2 功能模塊設計

　　3.2.1 接收組播流模塊

　　系統(tǒng)啟動時，流媒體服務器讀取并解析SDP文件，獲得每個直播頻道的組播參數(shù)，加入組播組，開始接收組播流數(shù)據(jù)。針對組播的網(wǎng)絡特性，在該模塊中設置接收緩沖隊列，根據(jù)接收RTP包的序號對組播流做排序處理，確保將RTP數(shù)據(jù)按照發(fā)送順序寫入緩沖文件。

　　3.2.2 緩沖文件操作模塊

　　該模塊包括將數(shù)據(jù)寫入緩沖文件和從緩沖文件中讀取數(shù)據(jù)的功能。本方案采用了緩沖技術對文件讀寫操作做優(yōu)化。對緩沖文件讀取時，為了快速定位，需要對緩沖文件按照時間建立索引。由于緩沖文件不斷增長變化，緩沖文件的索引也要同步更新，因此需要單獨生成索引文件、音頻數(shù)據(jù)文件和視頻數(shù)據(jù)文件。索引項數(shù)據(jù)結構如下：

　　typedef struct tagRTPFileIndex

　　{

　　time_t lTime; // 索引時間（秒）

　　int iVideoFileNum; // 視頻文件序號

　　int iVideoOffset; // 視頻文件偏移

　　int iAudioFileNum; // 音頻文件序號

　　int iAudioOffset; // 音頻文件偏移

　　}RTP_FILE_IDX_T;

　　3.2.3 延時續(xù)播請求處理模塊

　　流媒體服務器處理延時續(xù)播的流程與正常點播流程大致相同，但是操作的文件由普通流媒體文件改為緩沖文件，定位文件的時間參數(shù)也有所不同。本方案的實現(xiàn)中與播放器端約定以點播文件名后綴為“TS”標識延時續(xù)播點播請求。同時約定定位文件的時間參數(shù)表示點播時間據(jù)當前時間的間隔時長。

　　3.3 關鍵技術及解決方案

　　3.3.1 緩沖文件讀寫操作

　　流媒體系統(tǒng)運行過程中，隨著用戶數(shù)量的增加，系統(tǒng)對流媒體文件的訪問頻率也迅速增加。如果采取直接讀取文件的方式，很容易造成系統(tǒng)的I/O性能瓶頸。同時，延時續(xù)播系統(tǒng)需要不間斷地接收Broadcaster組播的RTP數(shù)據(jù)流，每個直播頻道以50-100包/秒的頻率發(fā)送RTP數(shù)據(jù)。如果以這個頻率對緩沖文件進行寫操作，將使系統(tǒng)的I/O性能急劇惡化。

　　本方案采用了緩沖技術優(yōu)化文件寫入操作。在寫入緩沖文件前，先將RTP數(shù)據(jù)包在內存中整理成一個相對較大的數(shù)據(jù)塊，再一次寫入緩沖文件，大大降低了I/O操作頻率。對于文件讀取操作，則借鑒操作系統(tǒng)虛擬內存管理技術對系統(tǒng)訪問的文件內容在內存中做了一級緩沖處理，有效降低了系統(tǒng)的IO訪問頻率。

　　讀取操作處理流程如圖4所示，首先確定緩沖內存塊大?。ū痉桨笧?K），然后對磁盤文件按照內存塊大小進行劃分，建立磁盤文件MAP。MAP采用數(shù)組作為存儲結構，記錄對應磁盤文件分塊的起始位置、結束位置、分塊編號，以及對應內存緩沖塊指針等信息。內存緩沖塊中設置一個標志記錄當前對應磁盤分塊的編號。

　　讀取磁盤文件時，按照以下步驟進行操作：

　　1． 根據(jù)讀取位置在文件內的偏移計算出對應的分塊編號；

　　2． 查找磁盤文件MAP；

　　3． 如果MAP項中內存緩沖塊指針為空，轉第7步；

　　4． 根據(jù)MAP項內存緩沖塊指針，訪問內存緩沖塊；

　　5． 如果內存緩沖塊記錄的分塊編號不等于該分塊編號，轉第7步；

　　6． 從內存緩沖塊中讀取文件內容；

　　7． 在內存緩沖塊鏈表中按照最近最少使用規(guī)則（LRU）確定淘汰塊；

　　8． 讀取磁盤文件塊的內容到淘汰塊中，修改內存緩沖塊文件分塊編號；

　　9． 修改MAP項內存緩沖指針，指向該淘汰塊，轉第6步。

　　本方案對系統(tǒng)IO性能的改善體現(xiàn)在兩個方面。首先對磁盤文件采取了按“塊”讀取的方式，實現(xiàn)了虛擬存儲管理中的預調策略。而對流媒體文件的訪問具有很強的順序性，預調策略能有效提高內存緩沖區(qū)的命中率。用戶數(shù)量增加時，各用戶對文件訪問的位置具有一定的分布特性。在某一時刻容易集中在文件的某一區(qū)域，比如影片的起始位置往往是訪問較頻繁的區(qū)域。這時，用戶對文件訪問的位置出現(xiàn)重疊，后訪問的用戶就可以直接從內存緩沖區(qū)中讀取文件內容，減少了對磁盤文件的讀取操作。

　　本方案實現(xiàn)中，對用戶訪問流媒體文件進行計數(shù)，根據(jù)計數(shù)動態(tài)調整內存緩沖塊的數(shù)量。當某文件的訪問計數(shù)增加時，增加緩沖塊數(shù)量，反之則減少緩沖塊數(shù)量。這樣能有效利用內存緩沖塊。

　　3.3.2 續(xù)播文件定位

　　通常情況下，流媒體系統(tǒng)中服務器和播放器的系統(tǒng)時間不能保持一致。這對延時續(xù)播電視中描述用戶需要續(xù)播的時間點造成了一定困難。本系統(tǒng)實現(xiàn)中，采用相對時間偏移的概念來描述用戶的續(xù)播需求。

　　如果用戶在收看直播節(jié)目的過程中進行了“暫?！辈僮?，播放器會記錄下該時間點。當戶用進

　　這種描述機制計算比較簡單，避免了因為服務器和播放器系統(tǒng)時間不一致造成的時刻混亂。

　　3.3.3 短延時處理

　　當用戶啟動延時續(xù)播功能時，播放器實際上由接收組播流模式轉變?yōu)辄c播模式。很明顯，點播操作對服務器造成的性能影響和對網(wǎng)絡造成的壓力要遠大于組播操作。因此在播放器端有必要采取適當?shù)拇胧┍苊庖蛴脩粽`操作或者惡意操作造成的短延時續(xù)播。

　　本方案在播放器端設置了最大接收緩沖隊列長度（比如60秒）。正常播放的情況下，接收緩沖隊列處于較小的長度（比如2秒）。當用戶暫停直播節(jié)目時，播放器停止讀取接收緩沖隊列的數(shù)據(jù)，但不立即停止接收組播數(shù)據(jù)。這種情況下，接收緩沖隊列長度逐漸增大。如果用戶在較短的時間間隔后進行了續(xù)播操作，播放器不用切換到延時續(xù)播模式，而是繼續(xù)從接收緩沖讀取數(shù)據(jù)。由于沒有停止接收組播數(shù)據(jù)，所以播放器接收緩沖隊列中的數(shù)據(jù)是連續(xù)的，只是隊列的長度發(fā)生了改變，處于比正常播放情況更長的狀態(tài)。如果用戶暫停的時間較長，或者進行了反復的暫停操作，接收緩沖隊列達到了最大長度，播放器停止接收組數(shù)據(jù)，當用戶再次續(xù)播操作時，轉入延時續(xù)播模式。

　　這種處理機制在播放器屏蔽了大多數(shù)短延時續(xù)播操作，即滿足了用戶的需求，又有效降低了服務器端和網(wǎng)絡的壓力。

　　4 結束語

　　本方案針對延時續(xù)播需求設計，但是對播放器稍作修改還可以實現(xiàn)對直播節(jié)目按時點播的功能。由于本方案的實現(xiàn)主要是在流媒體服務器端增加功能模塊，對播放器端沒有太多的修改，對播放器的運行環(huán)境也沒有特殊的要求，容易實現(xiàn)對通用播放器的兼容。特別在嵌入式IPTV機頂盒應用中播放器端的運行環(huán)境比較苛刻，沒有硬盤和大容量內存的支撐，實現(xiàn)延時續(xù)播功能只能在服務器做改進，本方案在這種情況下有較大的應用空間。

　　5 本文作者創(chuàng)新點

　　? 在服務器端實現(xiàn)直播電視節(jié)目的“時移”功能，不受播放器運行環(huán)境的限制，適合嵌入式終端應用；

　　? 在服務器端采用緩沖技術改善文件讀寫性能，提高服務器并發(fā)服務能力；

　　? 在播放器端采用動態(tài)緩沖隊列屏蔽了“短延時”操作，提高系統(tǒng)的穩(wěn)定性。

　　請登陸: 維庫電子市場網(wǎng)（） 瀏覽更多信息