基于arm的嵌入式_網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)畢業(yè)設(shè)計(jì)

1、<p>　　a基于ARM的嵌入式 網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)</p><p><b>　　目錄</b></p><p>　　基于ARM的嵌入式-1 - 網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)-1 -</p><p><b>　　目錄-1 -</b></p><p>　　一、緒論-1 -<

2、;/p><p><b>　　研究意義-1 -</b></p><p><b>　　市場(chǎng)需求-1 -</b></p><p>　　目前視頻監(jiān)控系統(tǒng)國(guó)內(nèi)外常見(jiàn)方案設(shè)計(jì)-2 -</p><p>　　系統(tǒng)設(shè)計(jì)目標(biāo)-3 -</p><p>　　技術(shù)可行性-4 -</p>

3、;<p>　　二、嵌入式系統(tǒng)介紹-5 -</p><p>　　嵌入式系統(tǒng)定義-5 -</p><p>　　嵌入式系統(tǒng)特點(diǎn)-5 -</p><p>　　嵌入式系統(tǒng)的組成-6 -</p><p>　　三、視頻編解碼和網(wǎng)絡(luò)協(xié)議的選擇7</p><p>　　網(wǎng)絡(luò)傳輸協(xié)議的分析選擇7</p&g

4、t;<p>　　網(wǎng)絡(luò)傳輸協(xié)議的分析7</p><p>　　網(wǎng)絡(luò)協(xié)議的選擇和設(shè)計(jì)'12</p><p>　　視頻數(shù)據(jù)傳輸方式的選擇.13</p><p>　　圖像壓縮算法的分析選擇13</p><p>　　壓縮的必要性和可能性.13</p><p>　　系統(tǒng)視頻壓縮方法的選擇.14&l

5、t;/p><p>　　四、監(jiān)控系統(tǒng)方案設(shè)計(jì)15</p><p>　　監(jiān)控系統(tǒng)總體方案選擇15</p><p>　　監(jiān)控系統(tǒng)硬件方案設(shè)計(jì)16</p><p>　　嵌入式處理器的選擇16</p><p>　　Flash 的選擇18</p><p><b>　　網(wǎng)卡的選擇.18

6、</b></p><p>　　攝像頭的選擇18</p><p>　　存儲(chǔ)硬盤(pán)接口的選擇19</p><p>　　五、硬件平臺(tái)設(shè)計(jì)20</p><p>　　網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)的硬件架構(gòu)20</p><p>　　各模塊及接口設(shè)計(jì)21</p><p>　　存儲(chǔ)系統(tǒng)模塊及接口設(shè)

7、計(jì).21</p><p>　　串口電路設(shè)計(jì)28</p><p>　　調(diào)試接口電路30</p><p>　　USB HOST 接口設(shè)計(jì)31</p><p>　　監(jiān)控系統(tǒng)硬件整體方案設(shè)計(jì)31</p><p>　　監(jiān)控系統(tǒng)軟件整體方案設(shè)計(jì)32</p><p>　　軟件開(kāi)發(fā)平臺(tái)及開(kāi)發(fā)工

8、具的選擇.32</p><p>　　構(gòu)建嵌入式軟件平臺(tái)33</p><p>　　BootLoader 移植.34</p><p>　　移植Linux2.6.14 內(nèi)核.40</p><p>　　CGI 簡(jiǎn)介.43</p><p>　　監(jiān)控系統(tǒng)軟件方案.44</p><p>　　六、系

9、統(tǒng)的設(shè)備驅(qū)動(dòng)程序移植45</p><p><b>　　網(wǎng)卡驅(qū)動(dòng)移植46</b></p><p>　　核心板網(wǎng)卡移植.46</p><p>　　主板網(wǎng)卡移植48</p><p>　　攝像頭驅(qū)動(dòng)移植54</p><p>　　七、監(jiān)控系統(tǒng)軟件的設(shè)計(jì)及實(shí)現(xiàn)55</p>&l

10、t;p>　　監(jiān)控系統(tǒng)功能模塊作用及設(shè)計(jì)55</p><p>　　Linux下多線程編程技術(shù)57</p><p>　　系統(tǒng)視頻壓縮方法的選擇.58</p><p>　　視頻采集模塊軟件設(shè)計(jì)59</p><p>　　關(guān)于 Video4Linux60</p><p>　　多路圖像采集的實(shí)現(xiàn)64</p

11、><p>　　視頻編碼和解碼模塊設(shè)計(jì)64</p><p>　　JPEG 標(biāo)準(zhǔn)65</p><p>　　JPEG 解碼67</p><p>　　動(dòng)態(tài)圖像解碼的優(yōu)化67</p><p>　　獲取壓縮后每一幀大小67</p><p>　　WEB服務(wù)器搭建68</p><p

12、>　　PC上顯示模塊設(shè)計(jì).72</p><p>　　保存視頻文件的設(shè)計(jì)n</p><p>　　FTP服務(wù)器的設(shè)計(jì)16</p><p>　　系統(tǒng)運(yùn)行性能77</p><p>　　一、緒論 1.1研究意義</p><p>　　嵌入式是當(dāng)今最為熱門(mén)的概念之一，其應(yīng)用領(lǐng)域也非常之廣泛，無(wú)論是在工業(yè)控制、交

13、通管理、 信息家電、安防，還是個(gè)人手持設(shè)備，都有著非常廣泛的應(yīng)用。而且，隨著智能化、信息化和網(wǎng)絡(luò) 化發(fā)展，“后PC時(shí)代”（指的就是各種嵌入式計(jì)算機(jī))已經(jīng)來(lái)臨，這預(yù)示著嵌入式系統(tǒng)技術(shù)將會(huì)獲得 更為廣闊的發(fā)展空間。例如，在通信領(lǐng)域，數(shù)字技術(shù)正在全面取代模擬技術(shù)；在廣播電視領(lǐng)域，美 國(guó)己經(jīng)開(kāi)始實(shí)施模擬電視數(shù)字化，我國(guó)在2015年之前，也將會(huì)全面實(shí)現(xiàn)數(shù)字電視；在個(gè)人領(lǐng)域，各 種嵌入式產(chǎn)品也將為個(gè)人提供移動(dòng)數(shù)據(jù)處理和網(wǎng)絡(luò)通信等功能。而這些都離不開(kāi)

14、嵌入式系統(tǒng)技術(shù)的 應(yīng)用。</p><p>　　視頻監(jiān)控技術(shù)是一門(mén)集計(jì)算機(jī)技術(shù)、網(wǎng)絡(luò)技術(shù)和數(shù)字視頻技術(shù)于一體的綜合技術(shù)。計(jì)算機(jī)技術(shù) 和多媒體技術(shù)的迅速發(fā)展，以及自動(dòng)控制和多媒體技術(shù)也融入到視頻監(jiān)控系統(tǒng)中，監(jiān)控技術(shù)也得到 了迅速發(fā)展。過(guò)去的視頻監(jiān)控系統(tǒng)多數(shù)以模擬圖象信息為主，由于對(duì)圖象的處理和傳送均采用模擬 技術(shù)，不僅圖象質(zhì)量低，而且系統(tǒng)資源浪費(fèi)嚴(yán)重，不易組成復(fù)雜的網(wǎng)絡(luò)結(jié)構(gòu)，監(jiān)控功能可擴(kuò)展性差。</p>

15、<p>　　對(duì)本課題的研究，即對(duì)結(jié)合了嵌入式、網(wǎng)絡(luò)、圖像處理與數(shù)字視頻技術(shù)于一體的嵌入式網(wǎng)絡(luò)視 頻監(jiān)控系統(tǒng)的研究，意義明顯，不但有助于我們解決傳統(tǒng)監(jiān)控系統(tǒng)的缺點(diǎn)，提高監(jiān)控系統(tǒng)功能，而 且更是有實(shí)際意義，例如，國(guó)際反恐形勢(shì)、2008奧運(yùn)、國(guó)內(nèi)城鎮(zhèn)化與城市建設(shè)、部分應(yīng)用領(lǐng)域安全 事故頻發(fā)等，這些方面都需要有新一代的監(jiān)控系統(tǒng)保證。而且相對(duì)于其他IT業(yè)務(wù)，視頻監(jiān)控業(yè)務(wù)顯 得比較年輕正處于蓬勃發(fā)展期，仍有很大的發(fā)展空間，因此我認(rèn)為視頻

16、監(jiān)控市場(chǎng)將會(huì)是一個(gè)很有發(fā) 展?jié)摿Φ氖袌?chǎng)。</p><p><b>　　1.2市場(chǎng)需求</b></p><p>　　IP是Internet Protocol (因特網(wǎng)協(xié)議）的縮寫(xiě)，它是通過(guò)計(jì)算機(jī)網(wǎng)絡(luò)進(jìn)行交流的最常用的協(xié)議 之一。IP監(jiān)控解決方案就是通過(guò)有線或者無(wú)線IP網(wǎng)絡(luò)把視頻信息以數(shù)字化的形式來(lái)進(jìn)行傳輸。只要 是網(wǎng)絡(luò)可以到達(dá)的地方就一定可以實(shí)現(xiàn)視頻監(jiān)控和記錄，并且這種

17、監(jiān)控還可以與很多其它類(lèi)型的系 統(tǒng)進(jìn)行完美的結(jié)合。</p><p>　　據(jù)工業(yè)分析師J.P. Freeman和Co.，Inc.，的分析，僅美國(guó)安裝的模擬攝像機(jī)就有2，000萬(wàn)臺(tái)。 而在這2，000萬(wàn)臺(tái)中，超過(guò)1，500萬(wàn)臺(tái)是2002年出售的。在模擬攝像機(jī)銷(xiāo)量如日中天的背景下， 是逐漸浮出水面并且飛速發(fā)展的新一代產(chǎn)品…網(wǎng)絡(luò)攝像機(jī)。看它的發(fā)展勢(shì)頭，人們不難預(yù)見(jiàn)到它的 光輝前景；隨著數(shù)字化的理念的逐漸深入人心，在不遠(yuǎn)的將

18、來(lái)，它一定會(huì)取代模擬產(chǎn)品。</p><p>　　網(wǎng)絡(luò)攝像機(jī)是直接連入IP網(wǎng)絡(luò)的新一代產(chǎn)品，使用戶可以實(shí)現(xiàn)遠(yuǎn)程網(wǎng)絡(luò)上視頻觀看、存儲(chǔ)以及 對(duì)采集到的圖像信息做出分析以采取相應(yīng)的措施。網(wǎng)絡(luò)攝像機(jī)在2007年將占到市場(chǎng)的一半份額， 2005年，全球網(wǎng)絡(luò)視頻市場(chǎng)將有望達(dá)到7億9千萬(wàn)美元。</p><p>　　無(wú)論是單獨(dú)由網(wǎng)絡(luò)攝像機(jī)組成的解決方案，還是由模擬攝像機(jī)加視頻服務(wù)器組成的解決方案， 或者是兩

19、者混合組成的解決方案，IP監(jiān)控都已被證明是一種極具吸引力的解決方案。在越來(lái)越多的 原有行業(yè)應(yīng)用中，這種革命性的技術(shù)正在逐步取代傳統(tǒng)的監(jiān)控系統(tǒng)，在提高安全性的同時(shí)也進(jìn)一步 的降低了成本；而在許多新的應(yīng)用領(lǐng)域，它還是第一次用到，也因此開(kāi)創(chuàng)和激發(fā)了許多新的市場(chǎng)。</p><p>　　正是由于它系統(tǒng)的可擴(kuò)展性，IP監(jiān)控逐漸鞏固了其在現(xiàn)有監(jiān)視和遠(yuǎn)程監(jiān)控行業(yè)應(yīng)用的地位，也 加速了在其他新興行業(yè)的應(yīng)用，具體包括：</p&

20、gt;<p>　　教育：遠(yuǎn)程監(jiān)控學(xué)校的操場(chǎng)、走廊、大廳以及教室，也包括對(duì)一些建筑物的監(jiān)控；</p><p>　　交通：遠(yuǎn)程監(jiān)控火車(chē)站、鐵路軌道、高速公路以及機(jī)場(chǎng)的安全；</p><p>　　銀行：應(yīng)用于銀行各分支機(jī)構(gòu)或者是街頭的ATM取款機(jī)，替代繁冗的傳統(tǒng)安全監(jiān)視手段；</p><p>　　政府：安保和監(jiān)視應(yīng)用，通常集成到已有的系統(tǒng)中；</p&g

21、t;<p>　　商場(chǎng)：對(duì)各大型超市的分支機(jī)構(gòu)進(jìn)行安全監(jiān)視和遠(yuǎn)程管理，方便快速高效的管理；</p><p>　　工業(yè)：對(duì)生產(chǎn)線、后勤部門(mén)、庫(kù)房存儲(chǔ)系統(tǒng)進(jìn)行監(jiān)控，提高了廠區(qū)的安全性。</p><p>　　1.3目前視頻監(jiān)控系統(tǒng)國(guó)內(nèi)外常見(jiàn)方案設(shè)計(jì)</p><p>　　目前，國(guó)內(nèi)外對(duì)基于嵌入式網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)的研究，一般集中于嵌入式視頻監(jiān)控系統(tǒng)的設(shè)計(jì)、 嵌入式

22、操作系統(tǒng)的研究、視頻圖像的網(wǎng)絡(luò)傳輸以及視頻圖像處理等幾個(gè)方面。</p><p>　　在嵌入式視頻監(jiān)控系統(tǒng)設(shè)計(jì)方面一般是考慮系統(tǒng)的整體結(jié)構(gòu)和功能，例如小型網(wǎng)絡(luò)攝像機(jī)，系 統(tǒng)由圖像傳感器、嵌入式處理器、圖像處理器、網(wǎng)絡(luò)接口組成，通過(guò)壓縮優(yōu)化算法和背景差分算法 可以使攝像機(jī)實(shí)現(xiàn)實(shí)時(shí)的圖像壓縮、傳輸，并能跟蹤目標(biāo)，該系統(tǒng)的主要特點(diǎn)是實(shí)時(shí)性的提高；在 嵌入式操作系統(tǒng)方面，一般集中于嵌入式操作系統(tǒng)在視頻監(jiān)控系統(tǒng)中的應(yīng)用研究，

23、例如在嵌入式 Linux下對(duì)視頻采集設(shè)備驅(qū)動(dòng)程序的研究等；在對(duì)視頻圖像網(wǎng)絡(luò)傳輸?shù)难芯恐?，例如，IP組播方式 下的網(wǎng)絡(luò)視頻傳輸方案，可以大大的節(jié)約網(wǎng)絡(luò)帶寬，提高視頻的播放效率或者采用流媒體的格式傳 送視頻圖像數(shù)據(jù)，可以更好的實(shí)現(xiàn)視頻的傳輸及播放等；在視頻監(jiān)控領(lǐng)域關(guān)于視頻圖像處理的研究 一般是通過(guò)一定的圖形分析算法，實(shí)現(xiàn)目標(biāo)識(shí)別，目標(biāo)跟蹤，以及報(bào)警等功能。例如利用背景差分 算法在圖像處理中，控制運(yùn)動(dòng)模塊使攝像機(jī)可以跟蹤信息庫(kù)中的目標(biāo)網(wǎng)等。&

24、lt;/p><p>　　隨著壓縮編碼技術(shù)、計(jì)算機(jī)網(wǎng)絡(luò)技術(shù)和嵌入式系統(tǒng)的發(fā)展，以嵌入式視頻服務(wù)器為核心的視頻 監(jiān)控系統(tǒng)開(kāi)始在市場(chǎng)上嶄露頭角，該系統(tǒng)不需要處理模擬視頻信號(hào)的PC，而是把攝像機(jī)輸出的模擬 視頻信號(hào)通過(guò)內(nèi)置的嵌入式視頻編碼器直接轉(zhuǎn)換成數(shù)字信號(hào)，通過(guò)計(jì)算機(jī)網(wǎng)絡(luò)傳輸出去，嵌入式視 頻服務(wù)器具備視頻編碼處理、網(wǎng)絡(luò)通信、自動(dòng)控制等強(qiáng)大功能，直接支持網(wǎng)絡(luò)視頻傳輸和網(wǎng)絡(luò)管理，</p><p>　　

25、使得監(jiān)控范圍達(dá)到前所未有的廣度。</p><p>　　目前，國(guó)內(nèi)在這方面的研究剛剛起步，隨著數(shù)字技術(shù)的發(fā)展、圖像數(shù)字壓縮編碼技術(shù)及標(biāo)準(zhǔn)的 改進(jìn)、芯片成本的不斷下降、從事研究的單位越來(lái)越多。</p><p>　　現(xiàn)階段，嵌入式網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)的解決方案主要有以下幾種：</p><p>　　視頻采集芯片+DSP處理器。該方案中由視頻采集芯片完成圖像的預(yù)處理，由DSP完成

26、圖像 的編碼：基于MPEG-4、H.263或MJPEG標(biāo)準(zhǔn)的壓縮，經(jīng)以太網(wǎng)網(wǎng)絡(luò)傳輸。方案的主要缺點(diǎn)是控制 不夠靈活，不適合作系統(tǒng)控制，因?yàn)镈SP通常沒(méi)有強(qiáng)大的操作系統(tǒng)。</p><p>　　DSP處理器+嵌入式處理器。該方案采用由DSP完成基于MPEG-4、H.263或MJPEG標(biāo)準(zhǔn)的 圖像壓縮，在嵌入式處理器上運(yùn)行嵌入式OS(如嵌入式Linux)進(jìn)行系統(tǒng)控制和網(wǎng)絡(luò)傳輸。方案的主 要缺點(diǎn)是：由于有兩個(gè)主要的芯片，

27、設(shè)計(jì)、調(diào)試、使用較難，系統(tǒng)成本偏高。</p><p>　　圖像采集芯片+嵌入式處理器。該方案中，在嵌入式處理器上運(yùn)行嵌入式0S(如嵌入式Linux) 進(jìn)行系統(tǒng)控制和網(wǎng)絡(luò)傳輸。方案的主要缺點(diǎn)是：缺乏強(qiáng)大的圖像處理能力，很難滿足高實(shí)時(shí)性要求。</p><p>　　其他方案。DSP中央處理器完成圖像圖像壓縮編碼、編碼數(shù)據(jù)網(wǎng)絡(luò)傳輸和本地存儲(chǔ)，采用 CPLD完成圖像采集的控制邏輯的脫機(jī)遠(yuǎn)程視頻監(jiān)控方

28、案。</p><p><b>　　1.4系統(tǒng)設(shè)計(jì)目標(biāo)</b></p><p>　　系統(tǒng)的主體設(shè)計(jì)思想是將視頻前端和嵌入式Web服務(wù)器整合在一起，攝像頭傳送來(lái)的視頻信號(hào) 經(jīng)過(guò)壓縮后，通過(guò)內(nèi)部總線傳送到內(nèi)置的Web服務(wù)器。該服務(wù)器直接接上Intemet，網(wǎng)絡(luò)上用戶可 以直接用瀏覽器IE觀看服務(wù)器上的監(jiān)控圖像。而且，用戶還可以控制云臺(tái)從而對(duì)鏡頭的動(dòng)作或?qū)ο?統(tǒng)進(jìn)行配置操作。

29、</p><p>　　這種方案是當(dāng)前應(yīng)用較為廣泛的方法，使用了近來(lái)發(fā)展迅速的嵌入式技術(shù)、網(wǎng)絡(luò)化技術(shù)以及圖 像處理的技術(shù)，具有較高的技術(shù)水平。由于把視頻采集壓縮和Web功能集成到一個(gè)設(shè)備內(nèi)直接連入 網(wǎng)絡(luò)，達(dá)到即插即看，省掉很多復(fù)雜的電路，安裝也很方便(僅需設(shè)置IP地址)，用戶無(wú)需使用專(zhuān)用 軟件，在具有網(wǎng)絡(luò)接口的地方都可以直接使用。這種視頻監(jiān)控系統(tǒng)除應(yīng)用于遠(yuǎn)程網(wǎng)絡(luò)實(shí)驗(yàn)系統(tǒng)中， 也可以應(yīng)用在其它如交通監(jiān)管，醫(yī)院病床監(jiān)護(hù)

30、等各種設(shè)備之間距離較大的情況。</p><p>　　客戶機(jī)/服務(wù)器結(jié)構(gòu)(即c/s結(jié)構(gòu))，包括一個(gè)客戶端程序和一個(gè)服務(wù)器程序(運(yùn)行在被控制的計(jì)算 機(jī)端)。這種結(jié)構(gòu)可直接由客戶機(jī)向服務(wù)器發(fā)出具體的請(qǐng)求命令，或由服務(wù)器返回信息到客戶機(jī)，而 不必通過(guò)Web服務(wù)器，從而實(shí)現(xiàn)端到端控制，能夠滿足一定的實(shí)時(shí)性控制要求，是當(dāng)前流行的一種 網(wǎng)絡(luò)控制結(jié)構(gòu)，論文中也采用了曰S結(jié)構(gòu)。這樣我們就可以通過(guò)瀏覽器訪問(wèn)網(wǎng)關(guān)服務(wù)器，來(lái)得到攝 像機(jī)

31、以及其它設(shè)備的信息。</p><p>　　采用C/S結(jié)構(gòu)方案的優(yōu)點(diǎn)在于每一個(gè)網(wǎng)絡(luò)攝像機(jī)都有一個(gè)獨(dú)立的嵌入式Web服務(wù)器，因此每一 個(gè)網(wǎng)絡(luò)攝像機(jī)都具有獨(dú)立的IP地址，可以被上層系統(tǒng)通過(guò)網(wǎng)絡(luò)任意訪問(wèn)。而且每個(gè)攝像機(jī)都是獨(dú)立 工作，獨(dú)立傳輸，它們之間不存在任何的隸屬關(guān)系，各個(gè)單元都能獨(dú)立完成各自的任務(wù)而不受其它</p><p>　　單元的干預(yù)，同時(shí)，各個(gè)單元之間也能較好的保證在線擴(kuò)展、在線維護(hù)和

32、容錯(cuò)，可靠性高，符合網(wǎng) 絡(luò)測(cè)控的要求。系統(tǒng)總體結(jié)構(gòu)如圖1-1-1所示。</p><p>　　圖1-1-1總體結(jié)構(gòu)圖</p><p><b>　　1.5技術(shù)可行性</b></p><p>　　服務(wù)端我們需要移植Linux到目標(biāo)平臺(tái)上，這里我們采用的目標(biāo)平始是EduKit-IV教學(xué)平臺(tái)。移 植操作系統(tǒng)包括Bootloader的移植，內(nèi)核移植，文件系

33、統(tǒng)。這里采用的攝像頭是中星微ZC0303， 采用的USB接口，USB驅(qū)動(dòng)Linux內(nèi)核已支持，另外中星微的驅(qū)動(dòng)我們不難移植。視頻壓縮也不難 做到。另外在Linux下有很多優(yōu)秀的Web服務(wù)器，如Boa，我們僅需移植到EduKit-IV平臺(tái)上。當(dāng) 然這里需要目標(biāo)平臺(tái)能夠上網(wǎng)，EduKit-IV采用的是100M/10M自適應(yīng)的DM9000，其驅(qū)動(dòng)在Linux 內(nèi)核已有支持。</p><p>　　PC端，我們所只需其能上

34、網(wǎng)，并且?guī)в袨g覽器即可。</p><p><b>　　二、嵌入式系統(tǒng)介紹</b></p><p>　　2.1嵌入式系統(tǒng)定義</p><p>　　對(duì)于何為嵌入式系統(tǒng)，IEEE(國(guó)際電氣和電子工程師協(xié)會(huì))的定義是這樣的：用于控制、監(jiān)控或 者輔助于裝置、機(jī)器和工廠車(chē)間運(yùn)行操作的設(shè)施(Devices used to control,monitor,or

35、 assist the operation of equipment,machinery or plants)。這是從應(yīng)用上加以定義的，而目前國(guó)內(nèi)普遍被認(rèn)同</p><p>　　的定義是：以應(yīng)用為中心，以計(jì)算機(jī)技術(shù)為基礎(chǔ)，軟硬件可裁減適合應(yīng)用系統(tǒng)對(duì)功能、可靠性、成 本、體積、以及功耗等嚴(yán)格要求的專(zhuān)用計(jì)算機(jī)系統(tǒng)。它一般由嵌入式微處理器、外圍硬件設(shè)備、嵌 入式操作系統(tǒng)以及用戶的應(yīng)用程序等四個(gè)部分組成，用于實(shí)現(xiàn)對(duì)其他設(shè)

36、備的控制、監(jiān)視或管理等功 能。對(duì)于這個(gè)定義，可以從如下幾個(gè)方面來(lái)解讀：</p><p>　　嵌入式系統(tǒng)是面向用戶、面向產(chǎn)品、面向應(yīng)用的(特別是面向行業(yè)的應(yīng)用)，必須與具體的行 業(yè)應(yīng)用背景相結(jié)合，必須具有很強(qiáng)的專(zhuān)用性，而且必須可以根據(jù)實(shí)際需要合理裁減、利用。</p><p>　　嵌入式系統(tǒng)是將先進(jìn)的計(jì)算機(jī)技術(shù)、微電子技術(shù)以及各個(gè)行業(yè)的具體應(yīng)用相結(jié)合的產(chǎn)物。</p><p&

37、gt;　　嵌入式系統(tǒng)要求對(duì)軟硬件可以裁減，以適合各種需求。特別是對(duì)于軟件系統(tǒng)，其核心是往往 是一個(gè)幾KB到幾十KB的微內(nèi)核，可以對(duì)其進(jìn)行功能擴(kuò)展和裁減。</p><p>　　其實(shí)，嵌入式系統(tǒng)是一個(gè)外延極其廣泛的名詞，但凡與產(chǎn)品相結(jié)合的，具有嵌入式特點(diǎn)的系統(tǒng) 都可以看作嵌入式系統(tǒng)，如一個(gè)手持MP3，一個(gè)微型工業(yè)控制計(jì)算機(jī)都可以稱(chēng)作嵌入式系統(tǒng)。</p><p>　　2.2嵌入式系統(tǒng)特點(diǎn)<

38、/p><p>　　嵌入式系統(tǒng)和一般的PC機(jī)上的應(yīng)用系統(tǒng)不同，它有自己的特點(diǎn)：</p><p>　　嵌入式系統(tǒng)通常是面向特定應(yīng)用的。嵌入式CPU與通用型的最大不同就是嵌入式CPU大多 工作在為特定用戶設(shè)計(jì)的系統(tǒng)中，它通常都具有低功耗、體積小、集成度高等特點(diǎn)，能夠把在通用 型計(jì)算機(jī)系統(tǒng)中許多由板卡完成的功能集成在芯片內(nèi)部，從而有利于嵌入式系統(tǒng)設(shè)計(jì)趨于小型化， 移動(dòng)能力大大增強(qiáng)。</p>

39、<p>　　嵌入式系統(tǒng)是將先進(jìn)的計(jì)算機(jī)技術(shù)、半導(dǎo)體技術(shù)和電子技術(shù)與各個(gè)行業(yè)的具體應(yīng)用相結(jié)合后 的產(chǎn)物。這一點(diǎn)就決定了它必然是一個(gè)技術(shù)密集、不斷創(chuàng)新的知識(shí)密集型系統(tǒng)。</p><p>　　嵌入式系統(tǒng)的硬、軟件都必須高效率地設(shè)計(jì)，量體裁衣、去除冗余，針對(duì)具體需求，對(duì)系統(tǒng) 進(jìn)行合理配置，達(dá)到理想性能。</p><p>　　為了提高執(zhí)行速度和系統(tǒng)可靠性，嵌入式系統(tǒng)中的軟件一般都固化在

40、存儲(chǔ)器芯片中，而不是 存貯于磁盤(pán)等載體中。由于大部分嵌入式系統(tǒng)必須具有較高的實(shí)時(shí)性，因此對(duì)程序的質(zhì)量，特別是</p><p>　　可靠性，有著較高的要求。</p><p>　　5)嵌入式系統(tǒng)本身并不具備在其上進(jìn)行開(kāi)發(fā)的能力，都是通過(guò)交叉編譯開(kāi)發(fā)完成的，即采用宿 主機(jī)和目標(biāo)機(jī)的開(kāi)發(fā)模式，在PC上開(kāi)發(fā)完，編譯成功后下載到目標(biāo)機(jī)運(yùn)行的模式。</p><p>　　2.3嵌入

41、式系統(tǒng)的組成</p><p>　　一般而言，一個(gè)完整的嵌入式系統(tǒng)由四部分組成:嵌入式微處理器、嵌入式外圍設(shè)備、嵌入式操 作系統(tǒng)和嵌入式應(yīng)用軟件。系統(tǒng)結(jié)構(gòu)如圖2-1所示。</p><p>　　嵌人式應(yīng)用軟件 嵌入式中間件 嵌入式操作系統(tǒng)</p><p>　　三、視頻編解碼和網(wǎng)絡(luò)協(xié)議的選擇</p><p>　　盡管IP網(wǎng)絡(luò)技術(shù)近年來(lái)在網(wǎng)絡(luò)帶寬和網(wǎng)

42、絡(luò)速度方面有許多發(fā)展和改善，但相對(duì)于傳輸 數(shù)據(jù)量龐大的視頻信息而言，網(wǎng)絡(luò)速度依然是視頻傳輸中的瓶頸所在。因此，在有效利用現(xiàn) 有網(wǎng)絡(luò)資源基礎(chǔ)上，為了能提供較好的視頻傳輸質(zhì)量，采用何種網(wǎng)絡(luò)傳輸協(xié)議是解決該問(wèn)題 的關(guān)鍵所在；數(shù)字視頻的海量信息，如果不經(jīng)過(guò)壓縮，將會(huì)浪費(fèi)大量的資源，甚至造成系統(tǒng)</p><p><b>　　毫無(wú)意義。</b></p><p>　　因此，網(wǎng)絡(luò)傳輸

43、協(xié)議和視頻壓縮編碼的選擇成為網(wǎng)絡(luò)數(shù)字視頻應(yīng)用中的關(guān)鍵問(wèn)題，將直 接影響到數(shù)字視頻傳輸?shù)膶?shí)時(shí)性能和視頻監(jiān)控的質(zhì)量。</p><p>　　3.1網(wǎng)絡(luò)傳輸協(xié)議的分析選擇</p><p>　　3.1.1網(wǎng)絡(luò)傳輸協(xié)議的分析</p><p>　　一個(gè)基本的網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)模型如圖3-1所示。在網(wǎng)絡(luò)各層次中，物理層和數(shù)據(jù)鏈路 層是不能通過(guò)應(yīng)用程序編程實(shí)現(xiàn)的，編程設(shè)計(jì)時(shí)不考慮這兩層

44、。網(wǎng)絡(luò)層是將數(shù)據(jù)打包，選擇 適當(dāng)?shù)穆酚蓪?shù)據(jù)傳送，使用IP協(xié)議，傳輸層的任務(wù)是根據(jù)子網(wǎng)的特性最佳地利用網(wǎng)絡(luò)資 源，并以可靠和經(jīng)濟(jì)的方式為兩端主機(jī)建立傳輸連接，以透明的方式傳送報(bào)文，使用 TCP/UDP協(xié)議;應(yīng)用層確定進(jìn)程之間通信，是我們的編程任務(wù)，但無(wú)需選擇協(xié)議。所以為了 保證基于網(wǎng)絡(luò)的數(shù)字視頻傳輸?shù)膶?shí)時(shí)性和圖像的質(zhì)量，傳輸層協(xié)議的選擇是整個(gè)設(shè)計(jì)和實(shí)現(xiàn) 的關(guān)鍵關(guān)鍵之一。</p><p>　　圖3-1基本視頻網(wǎng)絡(luò)傳

45、輸系統(tǒng)</p><p>　　在目前的IS0網(wǎng)絡(luò)模型中，在IP之上使用了兩種傳輸協(xié)議：一種是傳輸控制協(xié)議TCP 協(xié)議；另一種是用戶數(shù)據(jù)報(bào)協(xié)議UDP協(xié)議。</p><p>　　1、TCP協(xié)議（傳輸控制協(xié)議/Transport Control Protocol)</p><p>　　TCP/IP協(xié)議最初是為非實(shí)時(shí)數(shù)據(jù)業(yè)務(wù)而設(shè)計(jì)的。IP協(xié)議負(fù)責(zé)主機(jī)之間的數(shù)據(jù)傳輸，不 進(jìn)行

46、檢錯(cuò)和糾錯(cuò)，因此，經(jīng)常發(fā)生數(shù)據(jù)丟失或失序現(xiàn)象。為保證數(shù)據(jù)的可靠傳輸，人們將 TCP用于IP數(shù)據(jù)的傳輸，以提高接收端的檢錯(cuò)和糾錯(cuò)能力。TCP是面向連接的可靠的網(wǎng)絡(luò) 協(xié)議，面向連接服務(wù)是電話系統(tǒng)服務(wù)模式的抽象，即每一次完整的數(shù)據(jù)傳輸都要經(jīng)過(guò)建立連 接、使用連接、終止連接的三次握手過(guò)程；并且當(dāng)檢測(cè)到數(shù)據(jù)包丟失或者錯(cuò)誤時(shí)，就會(huì)要求 發(fā)送端重新發(fā)送，這樣以來(lái)就不可避免引發(fā)了傳輸延時(shí)和網(wǎng)絡(luò)帶寬的問(wèn)題。由此看來(lái)，由于 TCP的重傳機(jī)制和擁塞控制機(jī)制，

47、TCP更適用于對(duì)傳輸可靠性高于實(shí)時(shí)性要求的信息傳輸。</p><p>　　2、UDP協(xié)議（用戶數(shù)據(jù)報(bào)協(xié)議/User Datagram Protocol)</p><p>　　UDP協(xié)議是建立在IP協(xié)議的基礎(chǔ)之上的，它是無(wú)連接的不可靠的網(wǎng)絡(luò)協(xié)議，提供無(wú)連 接的數(shù)據(jù)報(bào)服務(wù)。無(wú)連接服務(wù)是郵政系統(tǒng)服務(wù)的抽象。無(wú)連接服務(wù)不能保證數(shù)據(jù)報(bào)的先后順 序，不進(jìn)行分組出錯(cuò)的恢復(fù)和重傳、流控制，不保證傳輸?shù)目?/p>

48、靠性，但它能提供開(kāi)銷(xiāo)最小的、 快速的端到端通信服務(wù)。相對(duì)于TCP來(lái)說(shuō)，UDP有如下優(yōu)點(diǎn)：</p><p>　　時(shí)延小：UDP傳送數(shù)據(jù)前并不與對(duì)方建立連接，數(shù)據(jù)的傳輸不需要經(jīng)過(guò)“三次握手”， 發(fā)送完畢后也不需要釋放鏈接，因此減少了開(kāi)銷(xiāo)和發(fā)送數(shù)據(jù)之前的時(shí)延。</p><p>　　消耗小：UDP不使用擁塞控制，不保證可靠的交付，因此主機(jī)不需要維持具有許多 參數(shù)的、復(fù)雜的連接狀態(tài)表。</p&

49、gt;<p>　　網(wǎng)絡(luò)流量小、速度快：UDP對(duì)接收到的數(shù)據(jù)報(bào)不發(fā)送確認(rèn)信號(hào)，發(fā)送端不知道數(shù)據(jù) 是否被正確接收，也不會(huì)重發(fā)數(shù)據(jù)，這樣減少了網(wǎng)絡(luò)流量并且傳輸速度也比TCP更快。</p><p>　　從以上分析可知，UDP的傳輸延時(shí)低于TCP，能與視頻流很好的匹配，UDP相對(duì)于TCP 來(lái)說(shuō)更適合視頻的數(shù)據(jù)傳輸。由于UDP是無(wú)連接的不可靠的協(xié)議，無(wú)法保證實(shí)時(shí)視頻傳輸 業(yè)務(wù)的服務(wù)質(zhì)量，為了支持網(wǎng)絡(luò)實(shí)時(shí)傳輸服務(wù)

50、、QOS保證等問(wèn)題，1996年IETF(Intenet Engineering Task Force)的視頻音頻工作組制訂了 RTP實(shí)時(shí)傳輸協(xié)議。在協(xié)議設(shè)計(jì)時(shí)，RTP 被設(shè)計(jì)成緊密相關(guān)的兩個(gè)部分：</p><p>　　RTP協(xié)議(實(shí)時(shí)傳輸協(xié)議)，用來(lái)傳輸具有實(shí)時(shí)特點(diǎn)的數(shù)據(jù)。</p><p>　　RTCP協(xié)議(實(shí)時(shí)傳輸控制協(xié)議)，用來(lái)控制服務(wù)質(zhì)量。</p><p>　

51、　3、RTP協(xié)議（Realtime Transport Protocol)</p><p>　　RTP協(xié)議它只是一種應(yīng)用型的傳輸層協(xié)議，它基于組播或是單播網(wǎng)絡(luò)服務(wù)，提供端到端</p><p>　　的實(shí)時(shí)數(shù)據(jù)傳輸服務(wù)，本身并不提供任何傳輸?shù)目煽啃员ＷC和流量的擁塞控制機(jī)制。</p><p>　　RTP協(xié)議位于UDP之上，在功能上獨(dú)立于下面的傳輸層(UDP)和網(wǎng)絡(luò)層，但

52、不能單獨(dú)作 為一個(gè)層次存在。它在150網(wǎng)絡(luò)模型中的位置如圖3-2所示。</p><p><b>　　網(wǎng)絡(luò)層(IP)</b></p><p>　　圖3-2 RTP在TCP/IP模型中的位置</p><p>　　它通常是采用UDP/IP封裝數(shù)據(jù)包，將應(yīng)用程序生成的音、視頻數(shù)據(jù)被封裝在RTP信息</p><p>　　包中，每個(gè)

53、RTP信息包被封裝在UDP消息段中，然后再封裝在IP數(shù)據(jù)包中，完成音、視頻</p><p>　　數(shù)據(jù)的實(shí)時(shí)傳輸，因此RTP有著UDP傳輸?shù)膬?yōu)點(diǎn)。</p><p><b>　　RTP的數(shù)據(jù)包格式</b></p><p>　　RTP數(shù)據(jù)報(bào)的包頭格式如圖3-3所示：</p><p>　　CSRC標(biāo)識(shí)符(32>位</

54、p><p>　　我荷數(shù)據(jù)（Payload) 32位</p><p>　　圖3-3 RTP包頭格式</p><p>　　RTP數(shù)據(jù)協(xié)議負(fù)責(zé)對(duì)流媒體數(shù)據(jù)進(jìn)行封包并實(shí)現(xiàn)媒體流的實(shí)時(shí)傳輸，每一個(gè)RTP數(shù)據(jù) 報(bào)都由頭部(Header)和負(fù)載(Payload)兩個(gè)部分組成，其中頭部前12個(gè)字節(jié)的含義是固定的， 而負(fù)載則可以是不定長(zhǎng)連續(xù)音頻或視頻數(shù)據(jù)。</p><

55、;p>　　RTP包頭的時(shí)間戳和順序號(hào)是該協(xié)議的精華之處，其詳細(xì)解釋如下：</p><p>　　序列號(hào)（SequeneeNumber):16位長(zhǎng)度，每發(fā)送一個(gè)RTP數(shù)據(jù)包序列號(hào)加1，接收方根 據(jù)此可以發(fā)現(xiàn)是否有數(shù)據(jù)包丟失。例如，接收端的應(yīng)用程序接收到的RTP包流中在順序號(hào) 86和89之間有一個(gè)間隔，接收端就知道信息包87和88已經(jīng)丟失，并且采取措施來(lái)處理 相應(yīng)的措施處理丟失的數(shù)據(jù)。</p>&l

56、t;p>　　時(shí)間戳(Timestamp):犯位長(zhǎng)度，是實(shí)時(shí)數(shù)據(jù)傳輸?shù)闹匾畔?，它記錄了?shù)據(jù)塊第一字節(jié) 的采樣時(shí)間，采樣時(shí)間是線性單調(diào)增長(zhǎng)的，其時(shí)鐘頻率取決于RTP幀的載荷類(lèi)型。接收方 利用時(shí)間戳可以實(shí)現(xiàn)數(shù)據(jù)流的同步，包括同一數(shù)據(jù)流的流內(nèi)同步和不同數(shù)據(jù)流的流間同步， 完成對(duì)數(shù)據(jù)包的重組，并按照正常的速率回放數(shù)據(jù)。對(duì)于一些大的數(shù)據(jù)塊，一個(gè)數(shù)據(jù)塊被分 成多個(gè)RTP包，它們的時(shí)間戳相同。僅靠時(shí)間戳，不足以恢復(fù)數(shù)據(jù)包的順序，RTP利用提 供

57、的序列號(hào)以恢復(fù)數(shù)據(jù)包的順序，實(shí)現(xiàn)包丟失檢測(cè)，為網(wǎng)絡(luò)的實(shí)時(shí)傳輸提供網(wǎng)絡(luò)擁塞等信息。</p><p>　　4、RTCP 協(xié)議（Real-time Control Transport Protocol)</p><p>　　RTCP是和RTP —起使用的進(jìn)行流量控制和擁塞控制的服務(wù)控制協(xié)議，它是RTP的控制</p><p>　　協(xié)議，用于監(jiān)視網(wǎng)絡(luò)的服務(wù)質(zhì)量和數(shù)據(jù)接發(fā)雙方傳

58、遞信息，負(fù)責(zé)管理傳輸質(zhì)量在當(dāng)前應(yīng)用進(jìn) 程之間交換控制信息。在RTP會(huì)話期間，各參與者周期性地傳送RTCP包，包中含有己發(fā)送 的數(shù)據(jù)包的數(shù)量、丟失的數(shù)據(jù)包的數(shù)量等統(tǒng)計(jì)資料，因此，服務(wù)器可以利用這些信息動(dòng)態(tài)地 改變傳輸速率，甚至改變有效載荷類(lèi)型。</p><p>　　RTCP協(xié)議數(shù)據(jù)包格式</p><p>　　RTP提供一個(gè)控制協(xié)議(即RTCP)，用來(lái)支持其協(xié)議功能，圖3-4和3-5是RTCP

59、協(xié)議的 相關(guān)示意圖，直觀地描述了 RTcP包的打包結(jié)構(gòu)、包格式等。</p><p><b>　　0丨23</b></p><p>　　0 1 2 3 4 5 6 7 0 1』3 4 5 6了0 1 2 3 4 5 6 7 0 1 23 4 567</p><p>　　V=2 P RR count錢(qián)荷類(lèi)型(PT)Message leng

60、th</p><p>　　SSRC OF report sender</p><p>　　NRP timestamp(two 32-bit words)</p><p>　　RTP timestamp Send’s cumulative packet count Send's cumulative byte count</p><p&g

61、t;　　圖3-4 RTCP發(fā)送報(bào)告包頭格式</p><p><b>　　0123</b></p><p>　　~"0 i 2 3456701234567012 3 4 5 6 7 0 fY3 4—567</p><p>　　V=2 P RR count錢(qián)荷類(lèi)型(PT>Message length</p>&

62、lt;p>　　SSRC of report sender</p><p>　　SSRC of first source head from</p><p>　　—RTP timestamp</p><p>　　fraction lostCumulative number of lost packets</p><p>　　Ex

63、tended highest sequence mumber received estimate RTP packet inter arrival time first Timestamp of last SR report received elapsed time since last SR report received Reception Report</p><p>　　圖3-5 RTCP接收?qǐng)?bào)告包頭格

64、式 類(lèi)似于RTP數(shù)據(jù)包，每個(gè)RTCP報(bào)文以固定的包頭部分開(kāi)始，緊接著的是可變長(zhǎng)結(jié)構(gòu)元 素，類(lèi)型不同長(zhǎng)度也不同，但總是32位的整數(shù)倍，長(zhǎng)度在固定部分的長(zhǎng)度域中標(biāo)明。結(jié)構(gòu) 元素的意義由RTCP報(bào)文的類(lèi)型決定，因?yàn)橥ǔTCP包非常小，一般把多個(gè)RTCP包合并 為一個(gè)RTCP包，然后利用一個(gè)底層協(xié)議所定義的報(bào)文格式(例如UDP格式)進(jìn)行發(fā)送。</p><p>　　RTCP報(bào)文頭部參數(shù)首先要區(qū)別攜帶不同控制信息的RTCP

65、報(bào)文的類(lèi)型，RTCP報(bào)文的類(lèi) 型主要有以下幾種：（1)SR:發(fā)送報(bào)告，當(dāng)前活動(dòng)發(fā)送者發(fā)送、接收統(tǒng)計(jì)。（2)RR:接收?qǐng)?bào) 告，非活動(dòng)發(fā)送者接收統(tǒng)計(jì)。（3)SDES:源描述項(xiàng)，包括CNAME。（4)BYB:表示結(jié)束。（5)APP: 應(yīng)用特定函數(shù)。</p><p>　　其中最主要的RTCP報(bào)文是SR和RR:</p><p>　　SR(SenderReport)：發(fā)送方報(bào)告。由處于活躍狀態(tài)的信源發(fā)

66、送方發(fā)送，SR報(bào)文不 僅提供該端系統(tǒng)作為接收方的數(shù)據(jù)接收質(zhì)量反饋信息，而且還提供SSRC(同步源)標(biāo)識(shí)符、 RTP時(shí)間戮、發(fā)送包數(shù)以及發(fā)送字節(jié)數(shù)等與發(fā)送有關(guān)的信息。</p><p>　　RR(ReeeiverReport)：接收方報(bào)告。由實(shí)時(shí)數(shù)據(jù)接收方發(fā)送，RR報(bào)文針對(duì)每個(gè)信 源都提供報(bào)文丟失數(shù)、已收?qǐng)?bào)文的最大序列號(hào)、到達(dá)時(shí)間抖動(dòng)、接收最后一個(gè)SR的時(shí)間、 接收最后一個(gè)SR的延遲等信息。</p>&

67、lt;p>　　2、RTCP協(xié)議功能</p><p>　　根據(jù)上面的RTCP報(bào)文，RTCP可以完成以下功能：</p><p>　　擁塞控制和QOS監(jiān)測(cè)。提供數(shù)據(jù)發(fā)布的質(zhì)量反饋，這是RTCP最主要的功能。用 反饋信息的方法來(lái)提供分配數(shù)據(jù)的傳送質(zhì)量，這種反饋可以用來(lái)進(jìn)行流量的擁塞控制，也可 以用來(lái)監(jiān)視網(wǎng)絡(luò)和用來(lái)診斷網(wǎng)絡(luò)中的問(wèn)題。</p><p>　　標(biāo)識(shí)(Ident

68、ification)RTP數(shù)據(jù)分組只用一個(gè)隨機(jī)產(chǎn)生的32比特標(biāo)識(shí)符來(lái)標(biāo)識(shí)其數(shù) 據(jù)源。RTeP消息包含一個(gè)SDES(信息源描述，SoureeDescription)，用于保存一些文本形 式的信息，例如，會(huì)議參與者的全局惟一標(biāo)識(shí)符、用戶名稱(chēng)、E-mail地址、電話號(hào)碼等。</p><p>　　根據(jù)與會(huì)者的數(shù)量來(lái)調(diào)整RTCP包的發(fā)送率。前兩種功能要求所有參加者發(fā)送RTCP 包，因此，為了 RTP擴(kuò)展到大規(guī)模數(shù)量，速率必

69、須受到控制。RTCP控制報(bào)文的發(fā)送周期是 變化的，與報(bào)文長(zhǎng)度L、用戶數(shù)N和控制報(bào)文帶寬B相關(guān)：周期P=LxN/B。原因是RTP設(shè) 計(jì)成允許應(yīng)用自動(dòng)擴(kuò)展的模式，連接數(shù)可從幾個(gè)到上千個(gè)，如果每個(gè)參加者以固定速率發(fā)送 接收?qǐng)?bào)告，控制流量將隨參加者數(shù)量線性增長(zhǎng)，因此，速率必須按比例下降。</p><p>　　控制傳送會(huì)話控制信息量。參與會(huì)話的每個(gè)成員周期性地發(fā)送RTCP包，各站點(diǎn) 可據(jù)此估計(jì)或計(jì)算出參與通信的人數(shù)，以便及

70、時(shí)調(diào)節(jié)實(shí)時(shí)控制的信息量，使得控制信息量和 媒體業(yè)務(wù)量達(dá)到平衡。</p><p>　　5、RTP/RTCP協(xié)議工作流程</p><p>　　在具體實(shí)現(xiàn)時(shí)，可把RTP執(zhí)行程序看成是應(yīng)用程序的一部分，把RTP集成到應(yīng)用程序 中。在發(fā)送端，必須把執(zhí)行RTP協(xié)議的程序?qū)懭氲絼?chuàng)建RTP信息包的應(yīng)用程序中，然后應(yīng) 用程序把RTP信息包發(fā)送到UDP的套接接口；同樣，在接收端，RTP信息包通過(guò)UDP套接 接

71、口輸入到應(yīng)用程序，需要把執(zhí)行RTP協(xié)議的程序?qū)懭氲綇腞TP信息包中抽出媒體數(shù)據(jù)的 應(yīng)用程序中。</p><p>　　在應(yīng)用RTP會(huì)話時(shí)會(huì)使用兩個(gè)端口，一個(gè)給RTP，一個(gè)給RTCP。根據(jù)協(xié)議規(guī)定，RTP 和RTCP選用不同的網(wǎng)絡(luò)端口號(hào)，RTP選擇一個(gè)偶數(shù)的端口號(hào)，而RTCP則選用下一個(gè)奇數(shù) 的端口號(hào)。</p><p>　　RTP會(huì)話期間，由于網(wǎng)絡(luò)擁塞或延時(shí)時(shí)，丟棄數(shù)據(jù)包，而數(shù)據(jù)的接收方卻仍然

72、能夠根據(jù) 時(shí)間戳和順序號(hào)對(duì)丟失的或己混亂失序的數(shù)據(jù)包進(jìn)行重新組合，使得傳輸?shù)靡匝永m(xù)而不會(huì)產(chǎn) 生過(guò)分的延遲。在一次RTP會(huì)話中參與者周期的發(fā)送RTCP包，用來(lái)傳遞關(guān)于數(shù)據(jù)傳輸質(zhì)量 的反饋信息。為了監(jiān)測(cè)網(wǎng)絡(luò)服務(wù)質(zhì)量、通信帶寬以及交換會(huì)話用戶信息，RTCP把傳輸情況 的報(bào)告發(fā)送給所有參與者。RTCP包中含有已發(fā)送的數(shù)據(jù)包的數(shù)量、丟失的數(shù)據(jù)包的數(shù)量等 統(tǒng)計(jì)資料。因此，接收端可以利用這些信息動(dòng)態(tài)地改變傳輸速率，甚至改變有效載荷類(lèi)型。 RTP和RT

73、CP配合使用，它們能以有效的反饋和最小的開(kāi)銷(xiāo)使傳輸效率最佳化，因而特別適 合傳送網(wǎng)上的實(shí)時(shí)數(shù)據(jù)。根據(jù)用戶間的數(shù)據(jù)傳輸反饋信息，可以制定流量控制的策略，而會(huì) 話用戶信息的交互，可以制定會(huì)話控制的策略。</p><p>　　3.1.2網(wǎng)絡(luò)協(xié)議的選擇和設(shè)計(jì)</p><p>　　監(jiān)控系統(tǒng)中傳輸?shù)男畔⒂锌刂浦噶?、視頻數(shù)據(jù)。例如有客戶端退出，改變顏色等指令。</p><p>　

74、　控制指令需要點(diǎn)對(duì)點(diǎn)的安全可靠的傳輸。根據(jù)上面的分析采用TCP協(xié)議來(lái)可靠傳輸 發(fā)送控制指令。</p><p>　　視頻數(shù)據(jù)是一種實(shí)時(shí)多媒體數(shù)據(jù)，需要點(diǎn)對(duì)對(duì)點(diǎn)的實(shí)時(shí)傳輸。對(duì)于視頻多媒體數(shù)據(jù) 的傳輸來(lái)說(shuō)，時(shí)間軸上的連續(xù)性要求網(wǎng)絡(luò)的實(shí)時(shí)性傳輸和高帶寬，而且視頻數(shù)據(jù)具有數(shù)據(jù)量 大又允許有一定的數(shù)據(jù)錯(cuò)誤率和數(shù)據(jù)丟失率等特點(diǎn)，因此傳輸視頻數(shù)據(jù)實(shí)時(shí)性要求要高于可 靠性，所以在系統(tǒng)中采用建立在UDP上的RTP/RTCP協(xié)議對(duì)視頻

75、流進(jìn)行封裝、打包和同步 來(lái)傳輸視頻數(shù)據(jù)，可以使視頻的網(wǎng)絡(luò)傳輸延時(shí)和質(zhì)量達(dá)到最佳。經(jīng)過(guò)RTP協(xié)議封裝后的數(shù) 據(jù)在傳輸層用UDP封裝，然后經(jīng)過(guò)IP層打包發(fā)送到客戶端，實(shí)現(xiàn)遠(yuǎn)程視頻監(jiān)控。</p><p>　　由上面分析可知，視頻傳輸所需協(xié)議的整體架構(gòu)如圖3-6所示：</p><p>　　圖3-6視頻傳輸?shù)膮f(xié)議架構(gòu)</p><p>　　3.1.3視頻數(shù)據(jù)傳輸方式的選擇<

76、;/p><p>　　當(dāng)前的網(wǎng)絡(luò)中有三種通訊模式：?jiǎn)尾?、廣播、組播(多播)。</p><p>　　單播(Unicast)：主機(jī)之間采用“一對(duì)一”的通訊模式，網(wǎng)絡(luò)中的交換機(jī)和路由器對(duì) 數(shù)據(jù)只進(jìn)行轉(zhuǎn)發(fā)不進(jìn)行復(fù)制。服務(wù)器針對(duì)每個(gè)客戶機(jī)發(fā)送數(shù)據(jù)流，服務(wù)器流量=客戶機(jī)數(shù)量 x客戶機(jī)流量，在客戶機(jī)數(shù)量大、流量大的視頻應(yīng)用中會(huì)造成數(shù)據(jù)冗余，消耗過(guò)多的主干網(wǎng) 絡(luò)帶寬，表現(xiàn)為服務(wù)器響應(yīng)時(shí)間延長(zhǎng)，甚至停止響應(yīng)。&l

77、t;/p><p>　　廣播(Broadcast)：主機(jī)之間采用“一對(duì)所有”的通訊模式，允許主機(jī)把一個(gè)IP報(bào) 文發(fā)送給同一個(gè)網(wǎng)絡(luò)的所有主機(jī)，由于不是所有的主機(jī)都需要這些報(bào)文，因而浪費(fèi)網(wǎng)絡(luò)資源。</p><p>　　組播(Multicast)：主機(jī)之間“一對(duì)一組”的通訊模式，IP組播技術(shù)是目前能夠最大 限度地利用現(xiàn)有網(wǎng)絡(luò)帶寬資源的一種有效方法。其中心思想為通過(guò)一個(gè)特殊IP地址(D類(lèi)地 址)向一組主

78、機(jī)發(fā)送UDP數(shù)據(jù)報(bào)，這個(gè)特殊地址就代表一個(gè)“組”，所有加入了這個(gè)組的主 機(jī)可以接受到此組內(nèi)的所有數(shù)據(jù)，網(wǎng)絡(luò)中的交換機(jī)和路由器只向有需求者復(fù)制并轉(zhuǎn)發(fā)其所需 數(shù)據(jù)。主機(jī)可以向路由器請(qǐng)求加入或退出某個(gè)組，網(wǎng)絡(luò)中的路由器和交換機(jī)有選擇的復(fù)制并 傳輸數(shù)據(jù)，即只將組內(nèi)數(shù)據(jù)傳輸給那些加入該組的主機(jī)。這樣既能一次將數(shù)據(jù)傳輸給多個(gè)有 需要(加入組)的主機(jī)，又能保證不影響其他不需要(未加入組)的主機(jī)的其他通訊。</p><p>　　

79、相對(duì)于單播、廣播比較而一言，組播技術(shù)有其獨(dú)特的優(yōu)越性。在組播網(wǎng)絡(luò)中，即使用戶 數(shù)量成倍增長(zhǎng)，主干帶寬亦不會(huì)隨之增加。組播是一種允許一個(gè)或多個(gè)發(fā)送者(組播源)發(fā)送 單一的數(shù)據(jù)包到多個(gè)接收者(一次的，同時(shí)的)的網(wǎng)絡(luò)技術(shù)。組播源把數(shù)據(jù)包發(fā)送到特定組播 組，而只有屬于該組播組的地址才能接收到數(shù)據(jù)包。組播可以大大的節(jié)省網(wǎng)絡(luò)帶寬，因?yàn)闊o(wú) 論有多少個(gè)目標(biāo)地址，在整個(gè)網(wǎng)絡(luò)的任何一條鏈路上只傳送單一的數(shù)據(jù)包。</p><p>　　

80、根據(jù)前面的介紹，RTP/RTCP協(xié)議也支持組播通信方式，因此在我們的監(jiān)控系統(tǒng)設(shè)計(jì)中， 選擇組播作為視頻數(shù)據(jù)的傳輸方式。與單播協(xié)議相比，組播沒(méi)有糾錯(cuò)機(jī)制，發(fā)生丟包錯(cuò)包后 難以彌補(bǔ)，但可以通過(guò)一定的容錯(cuò)機(jī)制和QOS加以彌補(bǔ)。因此對(duì)于容錯(cuò)機(jī)制和QOS的處理 也是我們網(wǎng)路通信中重點(diǎn)考慮的問(wèn)題。</p><p>　　3.2圖像壓縮算法的分析選擇</p><p>　　數(shù)字視頻信號(hào)的數(shù)據(jù)大，必須對(duì)其進(jìn)行

81、壓縮才能節(jié)省存儲(chǔ)設(shè)備，才能有效利用信道帶寬。 視頻信號(hào)的壓縮理論主要依靠?jī)牲c(diǎn)：視頻信號(hào)本身具有時(shí)間、空間和統(tǒng)計(jì)相關(guān)性；人眼視覺(jué) 系統(tǒng)對(duì)視頻的主觀感知允許一定的失真。視頻壓縮算法利用這兩點(diǎn)可大幅度地壓縮數(shù)據(jù)量， 同時(shí)保證較好的主觀圖像質(zhì)量。</p><p>　　3.2.1壓縮的必要性和可能性</p><p>　　視頻信息具有直觀、形象、準(zhǔn)確和信息容量大等特點(diǎn)，但與其他數(shù)據(jù)相比，視頻的原始 數(shù)

82、據(jù)量非常大，如果不經(jīng)過(guò)壓縮，這樣的視頻數(shù)據(jù)幾乎沒(méi)有實(shí)用價(jià)值。例如：一幅640X480 分辨率的24位真彩色圖像如果不經(jīng)過(guò)壓縮處理，數(shù)據(jù)大小為640*480*3=9〇〇Kb，如果存 儲(chǔ)1000張這樣的圖片就需要將近IG的存儲(chǔ)空間，按照NTSC標(biāo)準(zhǔn)的幀速率30幀/秒，視 頻信號(hào)的傳輸率約力26.4Mb/s，遠(yuǎn)遠(yuǎn)高于計(jì)算機(jī)的數(shù)據(jù)傳輸速率。顯然，這樣大的數(shù)據(jù)量 不僅超出了計(jì)算機(jī)的存儲(chǔ)和處理能力，更是當(dāng)前通信信道的傳輸速率所不及的，這樣高速率 的

83、圖像信息是不可能直接在網(wǎng)絡(luò)上傳輸?shù)模膊豢赡苤苯哟鎯?chǔ)到存儲(chǔ)媒體上去。因此，無(wú)論 是為了存儲(chǔ)還是傳輸視頻數(shù)據(jù)，都必須進(jìn)行壓縮才具有實(shí)際意義。</p><p>　　由于圖像原始數(shù)據(jù)像素之間都存在著較強(qiáng)的相關(guān)性，因此可以采用某種編碼方法減少這 樣相關(guān)性，這樣就可以實(shí)現(xiàn)圖像壓縮;再者視頻圖像中間存在著大量的冗余信息，如果去掉 這些冗余信息，也就達(dá)到壓縮目的;再者還有一些信息是人眼無(wú)法識(shí)別的，生理視覺(jué)上可以 完全忽略的部分

84、，可以完全去除，這樣也就實(shí)現(xiàn)視頻圖像的壓縮。</p><p>　　視頻數(shù)據(jù)壓縮主要基于對(duì)各種圖像數(shù)據(jù)冗余度及視覺(jué)冗余度間的壓縮，包括如下一些方 法：統(tǒng)計(jì)冗余度的壓縮、空間冗余度的壓縮、時(shí)間冗余度的壓縮、視覺(jué)冗余度的壓縮。</p><p>　　3.2.2系統(tǒng)視頻壓縮方法的選擇</p><p>　　視頻壓縮技術(shù)是整個(gè)系統(tǒng)的關(guān)鍵之一，實(shí)現(xiàn)視頻監(jiān)控系統(tǒng)的最佳效果。在目前的用

85、到的 壓縮技術(shù)不外乎有以下兩種。</p><p>　　靜態(tài)圖像壓縮技術(shù)JPEG、MJPEG、JPEG2000等</p><p>　　JPEG是聯(lián)合圖像專(zhuān)家組(Joint Photogaphie Experts Group)的縮寫(xiě)。JPEG標(biāo)準(zhǔn)是國(guó)際</p><p>　　上彩色、灰度、靜止圖像的第一個(gè)國(guó)際標(biāo)準(zhǔn)，它包括基于DPCM(差分脈沖編碼調(diào)制、DCT(離 散余弦變

86、換)和Huffman編碼的有損壓縮算法兩個(gè)部分。前者不會(huì)產(chǎn)生失真，但壓縮此很??； 后一種算法進(jìn)行圖像壓縮是信息雖有損失但壓縮比可以很大，例如壓縮25倍左右時(shí)，人眼 基本上看不出失真。它不僅適合用于靜態(tài)圖像的壓縮，也可對(duì)連續(xù)運(yùn)動(dòng)圖像進(jìn)行壓縮； JPEG200〇采用的壓縮方法是小波變換的壓縮方法，處理較容易，可獲得比JPEG更大的壓 縮，但是目前的標(biāo)準(zhǔn)還不是很統(tǒng)一；MJPEG全名為“MotionJPEG”，MJPEG的壓縮算法與 JPEG

87、一脈相承，采用幀內(nèi)處理技術(shù)，主要優(yōu)點(diǎn)是因此每一幀都容易編輯、圖片質(zhì)量清晰等。 但相應(yīng)地，MJPEG對(duì)帶寬的要求也很高，同時(shí)也需要大量的存儲(chǔ)空間。</p><p>　　運(yùn)動(dòng)圖像壓縮技術(shù)：MPEG標(biāo)準(zhǔn)、H.26X系列標(biāo)準(zhǔn)</p><p>　　當(dāng)前研究視頻壓縮技術(shù)的國(guó)際組織主要有：國(guó)際電信聯(lián)盟（ITU，Internation Telecommucation Union)和國(guó)際標(biāo)準(zhǔn)化組織的運(yùn)動(dòng)圖像

88、專(zhuān)家組(MPEG，Moving Picture Experts Group)。他們分別制定了 H.26x系列標(biāo)準(zhǔn)和MPEG標(biāo)準(zhǔn)。這些標(biāo)準(zhǔn)原理是利用相應(yīng) 算法減少圖像空間的信息冗余度，利用運(yùn)動(dòng)估算與運(yùn)動(dòng)補(bǔ)償來(lái)減少圖像在時(shí)間方向上的冗余 度，以達(dá)到大幅度壓縮圖像信息的目的，以覆蓋很大的視頻速率范圍和應(yīng)用領(lǐng)域、支持不同 速率和不同的圖像質(zhì)量要求等條件的視頻業(yè)務(wù)。</p><p>　　其中，H.264和MPEG-4是當(dāng)前

89、運(yùn)動(dòng)圖像視頻壓縮領(lǐng)域的主流編碼算法。MPEG-4以及</p><p>　　H.264是基于幀重建算法來(lái)壓縮和傳輸數(shù)據(jù)的，它們壓縮倍數(shù)可達(dá)200倍，壓縮率極高且需 要更少的帶寬。雖然MPEG-4標(biāo)準(zhǔn)的主要內(nèi)容、編碼工具以及碼流格式基本己經(jīng)確立，但是 由于MPEG-4許多新編碼技術(shù)是建立在圖像分析與合成、計(jì)算機(jī)圖形、虛擬現(xiàn)實(shí)和計(jì)算機(jī)等 基礎(chǔ)學(xué)上，這些新的編碼技術(shù)要走向應(yīng)用還需要結(jié)合大量的工具和研究。由于MPEG-4算

90、法 復(fù)雜，硬件完全實(shí)現(xiàn)不客易，在現(xiàn)階段的MPEG-4產(chǎn)品中普遍使用的是一些改良的基于窄帶 傳輸?shù)膲嚎s技術(shù)，所以很大程度上還存在著圖像干擾及畫(huà)面失真的情況，而且在ARM嵌入 式系統(tǒng)上用純軟件MPEG-4方法也不會(huì)有好的效果。</p><p>　　由于該研究的目的是需要傳輸高質(zhì)量的圖像畫(huà)面，且對(duì)帶寬要求不高，另外對(duì)于硬件的 框架的設(shè)計(jì)，我們選擇ARM9作為微處理器，不適宜做復(fù)雜的運(yùn)算，經(jīng)過(guò)測(cè)試，在用ARM 做MPEG

91、-4時(shí)320*240至多只能做到15幀/秒，而對(duì)于用H.264算法，復(fù)雜度會(huì)加倍。所 以本課題中采用MJPEG壓縮算法進(jìn)行靜態(tài)或運(yùn)動(dòng)圖像的壓縮及解壓縮。在進(jìn)行壓縮時(shí)，接 受YUV4:2:2數(shù)字視頻信號(hào)，將其編碼為JPEG碼流輸出;在解壓縮時(shí)，接受JPEG碼流，將 其解碼為YUV4:2:2數(shù)字視頻信號(hào)，輸出顯示。</p><p>　　利用JPEG標(biāo)準(zhǔn)推薦的量化表，壓縮比25:1時(shí)候，數(shù)據(jù)在復(fù)原后人眼還是幾乎不能看

92、見(jiàn)區(qū)別的。一幀320X240象素的圖像經(jīng)JPEG壓縮后，大概在5K/幀左右，按每秒25幀計(jì) 算，大約125K/秒，在局域網(wǎng)10/10〇M的通信中完全能夠滿足要求。</p><p>　　四、監(jiān)控系統(tǒng)方案設(shè)計(jì)</p><p>　　利用IP網(wǎng)絡(luò)傳輸視頻數(shù)據(jù)的概念提出至今已經(jīng)有10多年了，將嵌入式視頻監(jiān)控系統(tǒng)和 發(fā)達(dá)的網(wǎng)絡(luò)系統(tǒng)相結(jié)合形成新一代嵌入式網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)是近幾年才一開(kāi)始出現(xiàn)的，人們 對(duì)嵌

93、入式網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)方案已經(jīng)進(jìn)行了多方面的研究，提出了各種不同解決方案，但是 到目前為止，還沒(méi)有一個(gè)比較完善的方案能解決所有的問(wèn)題，需要用戶根據(jù)實(shí)際需要構(gòu)造滿 足自己要求的方案。</p><p>　　4.1監(jiān)控系統(tǒng)總體方案選擇</p><p>　　目前常見(jiàn)的方案優(yōu)缺點(diǎn)如表4-1所示：</p><p>　　表4-1常見(jiàn)監(jiān)控系統(tǒng)方案優(yōu)缺點(diǎn)</p><

94、p>　　根據(jù)上面的方案比較，對(duì)于網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)來(lái)說(shuō)，方案1由于沒(méi)有強(qiáng)大的操作系統(tǒng)和 網(wǎng)絡(luò)協(xié)議棧，因此不太適合做網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng);方案2是不錯(cuò)的選擇，DSP專(zhuān)門(mén)處理圖像 處理，ARM處理控制指令，設(shè)計(jì)得當(dāng)會(huì)取得不錯(cuò)的效果，但是該方案采用了兩個(gè)處理器， 不但提高了成本，在設(shè)計(jì)、調(diào)試上更是帶來(lái)困難，需要較長(zhǎng)的開(kāi)發(fā)周期;方案3主要問(wèn)題是 缺乏強(qiáng)大的圖像處理能力，不能滿足高實(shí)時(shí)性要求。</p><p>　　但本文中

95、所設(shè)計(jì)的系統(tǒng)主要用于局域網(wǎng)內(nèi)的視頻監(jiān)控系統(tǒng)，以圖像畫(huà)面作為證據(jù)的場(chǎng)合， 如小區(qū)、校園、無(wú)人值守的倉(cāng)庫(kù)、機(jī)房、變電所、家庭監(jiān)控報(bào)警等并不需要實(shí)時(shí)性特別強(qiáng)的 領(lǐng)域。而且現(xiàn)在嵌入式微處理器的處理性能也大大提高，能達(dá)到好幾百兆，已經(jīng)能滿足一般 的處理計(jì)算能力。</p><p>　　因此我們采用的方案只用ARM作為核心處理器的方案3。該方案中采用純軟壓縮的方 式來(lái)壓縮視頻圖像，以節(jié)約成本，但畢竟ARM的運(yùn)算能務(wù)有限，如果做

96、JPEG-4壓縮，經(jīng) 研究認(rèn)證QCIF格式最多也只能達(dá)到15fps，因此我們的視頻格式采用MJPEG視頻流格式。 MJPEG具有良好的靜態(tài)圖像效果，適合于事后視頻處理，并且碼流大小固定，帶寬利用率 高，正好能滿足我們的要求。</p><p>　　4.2監(jiān)控系統(tǒng)硬件方案設(shè)計(jì)</p><p>　　嵌入式平臺(tái)硬件設(shè)備是整個(gè)監(jiān)控系統(tǒng)的基礎(chǔ)，在系統(tǒng)設(shè)計(jì)中占有至關(guān)重要的位置，硬件 的選擇成功與否直接決

97、定著系統(tǒng)功能的優(yōu)劣，如果不適合，不但浪費(fèi)了財(cái)力和物力，更是耽 誤了整個(gè)項(xiàng)目的進(jìn)度。因此，在硬件選擇上需要經(jīng)過(guò)不斷比較才能確定選型。</p><p>　　監(jiān)控系統(tǒng)中主要的硬件有：嵌入式處理器器、Flash、SDRAM、網(wǎng)卡、攝像頭以及外存 儲(chǔ)器等。</p><p>　　4.2.1嵌入式處理器的選擇</p><p>　　嵌入式開(kāi)發(fā)硬件平臺(tái)的選擇主要是嵌入式處理器的選擇。

98、在一個(gè)系統(tǒng)中嵌入式處理器內(nèi) 核主要取決于應(yīng)用的領(lǐng)域、用戶的需求、成本、開(kāi)發(fā)的難易程度等因素。</p><p>　　根據(jù)前面的方案比較分析，我們選擇ARM作為系統(tǒng)核心處理器，ARM架構(gòu)是第一款 RISC微處理器，是一種可擴(kuò)展、可移植、可集成的處理器。采用RISC架構(gòu)的ARM微處理 器一般有如表4-2所示的特點(diǎn)：</p><p>　　表4-2 ARM CPU特點(diǎn)</p><

99、p>　　基于以上的一些優(yōu)點(diǎn)，隨著更多應(yīng)用在嵌入式系統(tǒng)中的實(shí)現(xiàn)，作為32位結(jié)構(gòu)體系中的 翹楚，ARM在各種應(yīng)用領(lǐng)域里得了極其廣泛的應(yīng)用。目前在市場(chǎng)上常用的ARM處理器有 ARM7系列、ARM9系列。但ARM9代表了 ARM公司主流的處理器，得到了更多的應(yīng)用。 ARM9相對(duì)于ARM7來(lái)說(shuō)有了更多的優(yōu)點(diǎn)，主要表現(xiàn)在如下：</p><p>　　1、ARM9主頻更高</p><p>　　ARM

100、9采用5級(jí)流水線而ARM7為3級(jí)流水線。每一級(jí)流水都對(duì)應(yīng)CPU的一個(gè)時(shí)鐘周 期，如果一級(jí)流水中的邏輯過(guò)于復(fù)雜，使得執(zhí)行時(shí)間居高不下，必然導(dǎo)致所需的時(shí)鐘周期變 長(zhǎng)，造成CPU的主頻不能提升。所以流水線的拉長(zhǎng)，有利于CPU主頻的提高。在常用的芯 片生產(chǎn)工藝下，ARM7 —般運(yùn)行在l00MHz左右，而ARM9則至少在200MHz以上。</p><p>　　2、ARM9帶有 MMU、CACHE 等</p>

101、<p>　　MMU則是用來(lái)支持存儲(chǔ)器管理的硬件單元，滿足現(xiàn)代平臺(tái)操作系統(tǒng)內(nèi)存理的需要，它 主要包括兩個(gè)功能:一是支持虛擬/物理地址映射，二是提供不同存儲(chǔ)器地址空間的保護(hù)機(jī)制; 高速緩存的引入是基于如下事實(shí)，即處理器速度遠(yuǎn)遠(yuǎn)高于存儲(chǔ)器訪問(wèn)速度;如果存儲(chǔ)器訪問(wèn) 成為系統(tǒng)性能的瓶頸，則處理器再快也是浪費(fèi)，因?yàn)樘幚砥餍枰馁M(fèi)大量的時(shí)間在等待存儲(chǔ) 器上面。高速緩存正是用來(lái)解決這個(gè)問(wèn)題，它可以存儲(chǔ)最近常用的代碼和數(shù)據(jù)，以最快的速 度提供

102、給CPU處理(CPU訪問(wèn)Cache不需要等待)。</p><p>　　Cache以及MMU等硬件單元的引入，給系統(tǒng)程序員的編程模型帶來(lái)了許多全新的變化。 例如，系統(tǒng)實(shí)時(shí)性和系統(tǒng)軟件優(yōu)化上的考慮。</p><p>　　3、性能和效率的提升由于ARM9內(nèi)核采用的是哈佛架構(gòu)，擁有獨(dú)立的擁有獨(dú)立的指令和 數(shù)據(jù)總線，而ARM7為傳統(tǒng)的馮諾依曼結(jié)構(gòu);ARM9的5級(jí)流水線設(shè)計(jì)把存儲(chǔ)器訪問(wèn)和寄存 器寫(xiě)回放

103、在不同的流水上面。運(yùn)行同一段程序，ARM9的處理器可以比ARM7節(jié)省大約30% 左右的時(shí)鐘周期。</p><p>　　通過(guò)上面比較，結(jié)合項(xiàng)目需要，為了實(shí)現(xiàn)監(jiān)控系統(tǒng)功能，需要在嵌入式平臺(tái)實(shí)現(xiàn)視頻采 集、編碼、網(wǎng)絡(luò)傳輸?shù)?，因此在監(jiān)控系統(tǒng)中采用ARM9作為微處理器，而三星的ARM產(chǎn)品 價(jià)格便宜，性能穩(wěn)定，開(kāi)發(fā)資料豐富等優(yōu)勢(shì)，因此選用的是三星的ARM9 S3C2410X作為 微處理器。</p><p&

104、gt;　　S3C2410是三星公司針對(duì)工業(yè)級(jí)和民用級(jí)等多種應(yīng)用場(chǎng)合設(shè)計(jì)的一款性?xún)r(jià)比比較高的 32位RISC嵌入式微處理器，它是16/32位RISC嵌入式微處理器，它采用了 ARM920T核、</p><p>　　5級(jí)流水線，內(nèi)部帶有全性能的MMU(能支持WinCE、嵌入式Linux等多種嵌入式0S)，運(yùn) 行速度高達(dá)Zo3MHz，支持usBI.1的usB接口，而且擁有豐富的其他接口以備方便擴(kuò)展功 能。</p&

105、gt;<p><b>　　Flash 的選擇</b></p><p>　　目前市場(chǎng)上的Flash有兩種：NOR Flash和NAND Flash，這兩種Flash各有特點(diǎn)，從以</p><p><b>　　下幾方面進(jìn)行比較：</b></p><p><b>　　1、性能比較</b><

106、;/p><p>　　Flash閃存是非易失存儲(chǔ)器，可以對(duì)稱(chēng)為塊的存儲(chǔ)器單元塊進(jìn)行擦寫(xiě)和再編程。任何 Flash器件的寫(xiě)入操作只能在空或已擦除的單元內(nèi)進(jìn)行，所以大多數(shù)情況下，在進(jìn)行寫(xiě)入操 作之前必須先執(zhí)行擦除。NAND器件執(zhí)行擦除操作是十分簡(jiǎn)單的，而NOR則要求在進(jìn)行擦 除前先要將目標(biāo)塊內(nèi)所有的位都寫(xiě)為0。他們之間的性能比較如下：</p><p>　　NOR的讀速度比NAND稍快一些；</

107、p><p>　　NAND的寫(xiě)入速度比NOR快很多；</p><p>　　NAND的4ms擦除速度遠(yuǎn)比NOR的5s快；</p><p>　　NAND的擦除單元更小，相應(yīng)的擦除電路更少。</p><p><b>　　2、容量和成本</b></p><p>　　NAND Flash的單元尺寸幾乎是NOR器件

108、的一半，由于生產(chǎn)過(guò)程更為簡(jiǎn)單，NAND結(jié) 構(gòu)可以在給定的模具尺寸內(nèi)提供更高的容量，也就相應(yīng)地降低了價(jià)格。因此，以備N(xiāo)OR Flash 的容量較小，NAND Flash的容量較大，適合于數(shù)據(jù)存儲(chǔ)。經(jīng)過(guò)以上比較，NAND Flash在 性能和成本上相對(duì)于更適合作為本系統(tǒng)中的存取器，因此我們選用K29F2808作為系統(tǒng)種的 Flash存儲(chǔ)器，它是一款64MB的NAND型Flash，系統(tǒng)啟動(dòng)代碼、內(nèi)核及根文件系統(tǒng)放于 此。</p>

109、<p>　　另外，為了更流暢運(yùn)行Linux系統(tǒng)及應(yīng)用程序，使用2片32MB的HY57V561620的 SDARM。</p><p>　　4.2.3網(wǎng)卡的選擇</p><p>　　網(wǎng)卡的選擇主要考慮它的傳輸速率和芯片的通用性，因此系統(tǒng)中的網(wǎng)卡芯片采用了 DM9000以太網(wǎng)控制器，該網(wǎng)卡是10/10oMbPs自適應(yīng)通信速率的，經(jīng)過(guò)前面的計(jì)算能夠滿 足我們的需求，而且該網(wǎng)卡芯片驅(qū)動(dòng)在