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

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

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

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