目前，在PC機上實現數字電視的播放主要有兩種方案，一種是基于PCI總線的數字電視接收卡" title="接收卡">接收卡，另一種是基于USB總線的數字電視接收終端。
　　兩種方案各有利弊。前種方案硬件成本較后一種低，但是PC機的處理負擔比后種方案重。這兩種方案均不能實現對加擾節(jié)目的播放，且實現的復雜度都較高，開發(fā)周期較長。以下方案可有效解決其存在的問題：
　　(1)機頂盒專用芯片+CY7C68013芯片。
　　(2)機頂盒專用芯片+以太網接口芯片" title="接口芯片">接口芯片DM9000A。
　　本文所提出的系統(tǒng)采用方案(2)。這是因為DM9000A比CY7C68013更有價格優(yōu)勢，同時較容易實現。
1 系統(tǒng)結構
　　本數字電視接收終端方案采用機頂盒專用解碼芯片和以太網接口芯片DM9000A實現。解碼芯片選用STMicroelectronics公司的STi5517芯片，STi5517主頻可達180MHz，內置DVB的解擾模塊，可以處理加擾數據流。通過STi5517的EMI接口總線實現SDRAM、Flash以及DM9000A等的擴展，DM9000A是100MHz的非PCI以太網接口芯片。系統(tǒng)硬件框圖如圖1所示。

　　采用此方案實現的接收終端連接在有線電視網和以太網之間，在接收終端中內嵌Web服務器和簡單的流服務器功能。
　　用戶通過瀏覽器向接收終端的Web服務器提出請求，如節(jié)目搜索、獲取節(jié)目列表及節(jié)目的EIT信息等。Web服務器根據瀏覽器的請求執(zhí)行相應的動作，并將相應的靜態(tài)頁面或動態(tài)頁面發(fā)送到瀏覽器。如果用戶通過瀏覽器向Web服務器發(fā)送播放節(jié)目的請求，Web服務器將用戶所請求節(jié)目的描述性文件(PD file)返回給瀏覽器，同時啟動流服務器程序接收音視頻數據并將接收到的數據封裝為數據包發(fā)送。瀏覽器接收到PD file后，將PD file傳給流播放程序，流播放程序根據PD file內容，接收來自流服務器的數據包并播放。
2 設計要點
　　系統(tǒng)設計的要點是嵌入式Web服務器和嵌入式流服務器的實現。
2.1 嵌入式Web服務器
　　一個典型的Web服務器的系統(tǒng)結構如圖2所示。

　　雖然嵌入式Web服務器的容量可以很小，但也同樣具有典型Web服務器的特點和主要功能。嵌入式Web服務器應不僅給瀏覽器提供靜態(tài)網頁，同時還應具備動態(tài)生成網頁的功能。因此系統(tǒng)設計實現了嵌入式CGI的功能，它作為應用程序的一部分存在。
2.1.1 HTTP協議選擇
　　嵌入式Web服務器技術的核心是HTTP引擎。HTTP是一個應用層協議，使用TCP作為傳輸層協議。HTTP1.0不支持持續(xù)連接，對每一次請求和響應都要通過TCP的3次握手建立，這造成對網絡資源的浪費。通常，一個典型的網頁頁面由多個html文件和多個圖形組成，而為了完整接收這個頁面，需要為每個文件或圖形的接收建立一個連接，建立和關閉連接都需要消耗CPU及內存資源。HTTP1.1允許在一個已經建立的連接上進行多次HTTP交互，這樣可大大提高網絡和系統(tǒng)的執(zhí)行效率。另外，HTTP1.0沒有直接的緩沖控制(cache-control)，因此，對于一些客戶端已經接收過的靜態(tài)頁面，如靜態(tài)文本、圖片、圖標等會重復接收，這將增加CPU的負擔。而HTTP1.1增加了緩沖控制機制，將一些已經接收的靜態(tài)數據緩存起來，再次使用時則無需再次接收這些數據，從而減輕了網絡和CPU的負擔?；谝陨蟽牲c，本系統(tǒng)中的Web服務器采用HTTP1.1協議。
2.1.2 嵌入式通用網關接口eCGI
　　本系統(tǒng)采用CGI生成動態(tài)頁面，實現服務器和瀏覽器之間的數據交互。
　　通用網關接口CGI(Common Gateway Interface)定義了Web服務器主機對外服務的標準接口。其主要功能是在Web環(huán)境下，從客戶端傳送信息給Web服務器，Web服務器把接收到的有關信息放入環(huán)境變量，然后啟動所指定的CGI腳本以完成特定的工作，CGI腳本從環(huán)境變量中獲取相關信息運行，最后以HTML格式輸出相應的執(zhí)行結果返回給瀏覽器端。由于用戶能給CGI腳本傳遞不同的參數，所以CGI技術使得瀏覽器和服務器之間具有交互性。
　　標準的CGI程序需要有文件系統(tǒng)以及程序動態(tài)調用的支持，在嵌入式系統(tǒng)中實現標準的CGI將增加代碼量，而且也影響系統(tǒng)的執(zhí)行效率。本系統(tǒng)采取一種變通的方式實現CGI，稱之為eCGI以區(qū)別標準的CGI。
　　在eCGI服務器中，通過調用函數完成CGI程序的執(zhí)行。如果接收到瀏覽器的CGI請求，就需要找到相應的處理函數，eCGI通過查找鏈表方式解決此問題。
　　AddCgiFuncs(char*funcName，char*path，void*funcs)；
　　此函數用來建立eCGI服務器中的CGI處理函數的列表，funcName和path分別是處理函數的虛擬文件名和虛擬路徑。
　　void*LookupCgiFuncs(char*funcName，char*path)；
　　此函數用來查找CGI處理函數的指針，funcName和path是從解析瀏覽器請求中得到的處理函數的文件名和路徑。
　　eCGI服務器中有一些環(huán)境變量以及瀏覽器與服務器交互的參數，這些數據采用類似上面的機制處理。
　　cgiAddVar(char*varName，v_type_t vType，v_value_t value)；
　　此函數用來創(chuàng)建一個參數，并添加到參數列表中。varName是參數的名稱，vType是參數的類型，value是參數的初始值。
　　cgiSetValue(char*varName，v_value_t value)；
　　此函數用來設置參數的值。
　　cgiGetValue(char*varName，v_value_t*value)；
　　此函數用來獲得參數的值。
　　eCGI工作的主要流程與CGI相似，即解析瀏覽器請求中CGI相關的腳本信息，然后查找并調用相應的eCGI處理函數，服務器將處理結果通過html文件返回瀏覽器，結束本次eCGI進程。
2.2 嵌入式流服務器
2.2.1 傳輸協議" title="傳輸協議">傳輸協議選擇
　　流媒體" title="流媒體">流媒體是指在網絡中使用流技術傳輸的連續(xù)時基媒體。其特點是播放前不需要下載整個文件，而是采用邊接收邊播放的方式。進行實時流媒體數據的傳輸可以采用UDP、HTTP、RTP等多種協議，本系統(tǒng)采用RTP協議。RTP數據報頭部格式如圖3所示。

　　從RTP數據報的格式不難看出，它包含了傳輸媒體的類型、格式、序列號、時間戳以及是否有附加數據等信息。這些都為流媒體實時傳輸提供了基礎，它可以建立在底層的面向連接或面向非連接的傳輸協議之上。在典型的應用場合，RTP是在傳輸協議之上(如TCP、UDP)作為應用程序的一部分實現的。雖然TCP提供可靠的連接，但是它的網絡開銷遠大于UDP，因此本系統(tǒng)采用UDP協議承載RTP數據。
2.2.2 封裝RTP數據包
　　在RFC2250(RTP Payload Format for MPEG1/MPEG2 Video)中定義了MPEG音視頻流的封裝格式。對于MPEG2數據流，可以采用兩種封裝格式，一種是將MPEG2傳輸流(TS)作為RTP負載封裝到數據包，另一種方式是將MPEG2基本流(ES)數據直接封裝到RTP數據包。后一種方式復雜程度較高，同時加大了服務器端的負擔，因此，采用第一種封裝方式。
　　將TS數據封裝到RTP數據包時，每個RTP數據包中必須包含整數個TS包，每一個RTP數據包將攜帶一個由發(fā)送端90kHz的參考時鐘產生的時間戳，發(fā)送端的這個時鐘(STC)與節(jié)目流中的PCR同步。
　　接收終端在接收音視頻節(jié)目時，首先接收PCR數據，并將接收到的第一個PCR直接設置到STC。當接收到后續(xù)的PCR時，則比較PCR與STC的值，根據差值調整PWM，從而達到調整系統(tǒng)時鐘振蕩頻率的目的。經過PCR調整的系統(tǒng)時鐘將與前端編碼器的時鐘同步。
　　音視頻數據的接收與發(fā)送流程如圖4所示。