1 引言

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

　　2 網絡直播電視基本原理

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

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

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

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

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

　　3.1 基本原理

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

　　3.2 功能模塊設計

　　3.2.1 接收組播流模塊

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

　　3.2.2 緩沖文件操作模塊

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

　　typedef struct tagRTPFileIndex

　　{

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

　　int iVideoFileNum; // 視頻文件序號

　　int iVideoOffset; // 視頻文件偏移

　　int iAudioFileNum; // 音頻文件序號

　　int iAudioOffset; // 音頻文件偏移

　　}RTP_FILE_IDX_T;

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

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

　　3.3 關鍵技術及解決方案

　　3.3.1 緩沖文件讀寫操作

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

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

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

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

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

　　2． 查找磁盤文件MAP；

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

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

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

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

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

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

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

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

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

　　3.3.2 續(xù)播文件定位

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

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

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

　　3.3.3 短延時處理

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

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

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

　　4 結束語

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

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

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

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

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

　　請登陸: 維庫電子市場網（） 瀏覽更多信息