【正文】 標地址，在整個網(wǎng)絡的任何一條鏈路上只傳送單一的數(shù)據(jù)包。 法的分析選擇 數(shù)字視頻信號的數(shù)據(jù)大，必須對其進行壓縮才能節(jié)省存儲設備，才能有效利用信道帶寬。例如：一幅 640X480 分辨率的 24位真彩色圖像如 果不經(jīng)過壓縮處理，數(shù)據(jù)大小為 640*480*3=9〇〇 Kb， 如果存 儲 1000張這樣的圖片就需要將近 IG的存儲空間，按照 NTSC標準的幀速率 30幀 /秒，視 頻信號的傳輸率約力 ， 遠遠高于計算機的數(shù)據(jù)傳輸速率。再者視頻圖像中間存在著大量的冗余信息，如果去掉 這些冗余信息，也就達到壓縮目的 。在目前的用到的 壓縮技術(shù)不外乎有以下兩種。它不僅適14 合用于靜態(tài)圖像的壓縮，也可對連續(xù)運動圖像進行壓縮； JPEG200〇 采用的壓縮方法是小波變換的壓縮方法，處理較容易，可獲得比 JPEG更大的壓 縮，但是目前的標準還不是很統(tǒng)一； MJPEG全名為 “MotionJPEG”， MJPEG的壓縮算法與 JPEG 一脈相承，采用幀內(nèi)處理技術(shù)，主要優(yōu)點是因此每一幀都容易編輯、圖片質(zhì)量清晰等。這些標準原理是利用相應 算法減少圖像空間的信息冗余度，利用運動估算與運動補償來減少圖像在時間方向上的冗余 度，以達到大幅度壓縮圖像信息的目的，以覆蓋很大的視頻速率范圍和應用領(lǐng)域、支持不同 速率和不同的圖像質(zhì)量要求等條件的視頻業(yè)務。由于 MPEG4算法 復雜，硬件完全實現(xiàn)不客易，在現(xiàn)階段的 MPEG4產(chǎn)品中普遍使用的是一些改良的基于窄帶 傳輸?shù)膲嚎s技術(shù)，所以很大程度上還存在著圖像干擾及畫面失真的情況，而且在 ARM嵌入 式系統(tǒng)上用純軟件 MPEG4方法也不會有好的效果。在解壓縮時，接受 JPEG碼流，將 其解碼為 YUV4:2:2數(shù)字視頻信號，輸出顯示。 15 目前常見的方案優(yōu)缺點如表 41所示： 根據(jù)上面的方案比較，對于網(wǎng)絡視頻監(jiān)控系統(tǒng)來說，方案 1由于沒有強大的操作系統(tǒng)和 網(wǎng)絡協(xié)議棧，因此不太適合做網(wǎng)絡視頻監(jiān)控系統(tǒng) 。而且現(xiàn)在嵌入式微處理器的處理性能也大大提高，能達到好幾百兆，已經(jīng)能滿足一般 的處理計算能力。 嵌入式平臺硬件設備是整個監(jiān)控系統(tǒng)的基礎，在系統(tǒng)設計中占有至關(guān)重要的位置，硬件 的選擇成功與否直接決定著系統(tǒng)功能的優(yōu)劣，如果不適合，不但浪費了財力和物力，更是耽 誤了整個項目的進度。在一個系統(tǒng)中嵌入式處理器內(nèi) 核主要取決于應用的領(lǐng)域、用戶的需求、成本、開發(fā)的難易程度等因素。但 ARM9代表了 ARM公司主流的處理器，得到了更多的應用。在常用的芯 片生產(chǎn)工藝下， ARM7 — 般運行在 l00MHz左右，而 ARM9則至少在 200MHz以上。高速緩存正是用來解決這個問題，它可以存儲最近常用的代碼和數(shù)據(jù)，以 最快的速 度提供給 CPU處理 (CPU訪問 Cache不需要等待 )。ARM9的 5級流水線設計把存儲器訪問和寄存 器寫回放在不同的流水上面。 Flash 的選擇 目前市場上的 Flash有兩種 ： NOR Flash和 NAND Flash， 這兩種 Flash各有特點，從以 下幾方面進行比較： 性能比較 Flash閃存是非易失存儲器，可以對稱為塊的存儲器單元塊進行擦寫和再編程。 容量和成本 NAND Flash的單元尺寸幾乎是 NOR器件的一半，由于生產(chǎn)過程更為簡單， NAND結(jié) 構(gòu)可以在給定的模具尺寸內(nèi)提供更高的容量，也就相應地降低了價格。 網(wǎng)卡的選擇主要考慮它的傳輸速率和芯片的通用性，因此系統(tǒng)中的網(wǎng)卡芯片采用了 DM9000以太網(wǎng)控制器，該網(wǎng)卡是 10/10oMbPs自適應通信速率的，經(jīng)過前面的計算能夠滿 足我們的需求，而且該網(wǎng)卡芯片驅(qū)動在 ，只需要稍作修改就可 以正常運行起來。 CCD電荷耦合器制作技術(shù)起步早，技術(shù)成熟，成像質(zhì)量相對 CMOS光電傳感器有一定 優(yōu)勢。 硬盤接口使硬盤與主機系統(tǒng)間的連接部件，作用是在硬盤緩存和主機內(nèi)存之間傳輸數(shù)據(jù)。光纖通道只在高端服務器上，價格昂貴 。 五、硬件平臺設計 圖 51系統(tǒng)硬件結(jié)構(gòu)圖 如圖 51所示為智能家居系統(tǒng)的硬件結(jié)構(gòu)圖。 ?網(wǎng)卡接口：采用 DM9000網(wǎng)絡控制芯片，為遠程網(wǎng)絡控制提供支持。 BANK0可以設置為 16位、 32位訪問； ? 8個地址空間中， 6個地址空間可以用于 ROM、 SRAM等存儲器， 2個用于 ROM、 SRAM、SDRAM等存儲器 。 Bank0Bank5的起始地址和空間大小都是固定 的，Bank6的起始地址是固定的，但是空間大小和 Bank7 — 樣是可變的，可以配置為 2/4/8/16/32M/64M/128M。 Address 2MB 4MB 8MB 16MB 32MB Bank 6 Siart address 0btc00_0000 0btc00_0000 Qxc00_0000 Qxc00_0000 0xc00_0000 End address OxclLffff 0xc3Lffff 0xc7Lffff QxcfLHFf QxdfLHFf Bank 7 S1ert address QKC20_0000 163。ss 2MB 16Mb (1M x 3 x 2banks) x 1 ea A20 x10 (512Kx 16 x 2banks) x 1 ea 4MB xS 16Mb (2M x 4 x 2b。 過外部 nWAIT引腳來延長 nOE持續(xù)時間。 表 521 Bank6/Bank7 地址 (映射地址為 0X00000000)所在的空間，所以必須在第一次訪問 ROM前設置 BANK0數(shù)據(jù) 寬度，該數(shù)據(jù)寬度是由復位后 OM[1:0]的邏輯電平?jīng)Q定的，圖 523所示。21 圖 521為 S3C2410復位后的存儲器地址分配圖。 ?調(diào)試模塊： JTAG用來下載 Bootfoader和在線調(diào)試程序， RS232接口用來輸出打印 信息。 ?存儲設備：存儲設備主要包括了 SDRAM、 NANDFLASH和 NORFLASH。 本系統(tǒng)需要用硬盤來存儲經(jīng)過 MJPEG編碼的視頻信號，于是制定其存儲方案的首要問 題是要選擇一種能夠達到本系統(tǒng)數(shù)據(jù)傳輸速度要求、性能價格比較好的硬盤接口。從整體的角度上，硬盤接口分為 SCSI、 USB、 IDE、 SATA和光纖通道五種。 近年，隨著 CMOS電路消噪技術(shù)的不斷發(fā)展，為生產(chǎn)高密度優(yōu)質(zhì)的 CMOS圖像傳感器提供 了良好的條件，產(chǎn)品質(zhì)量有了很大的提高，能夠滿足絕大部分場合的用途，在傳真機、掃描 儀、數(shù)字攝像機、安全偵測系統(tǒng)等方面得到廣泛應用。但兩種傳感器各有特點。經(jīng)過以上比較 ， NAND Flash在 性能和成本上相對于更適合作為本系統(tǒng)中的存取器，因此我們選用 K29F2808作為系統(tǒng)種的 Flash存儲器，它是一款 64MB的 NAND型 Flash， 系統(tǒng)啟動代碼、內(nèi)核及根文件系統(tǒng)放于 此。NAND器件執(zhí)行擦除操作是十分簡單的，而 NOR則要求在進行擦 除前先要將目標塊內(nèi)所有的位都寫為 0。 通過上面比較，結(jié)合項目需要，為了實現(xiàn)監(jiān)控系統(tǒng)功能，需要在嵌入式平臺實現(xiàn)視頻采 集、編碼、網(wǎng)絡傳輸?shù)龋虼嗽诒O(jiān)控系統(tǒng)中采用 ARM9作為微處理器，而三星的 ARM產(chǎn)品 價格便宜，性能穩(wěn)定，開發(fā)資料豐富等優(yōu)勢，因此選用的是三星的 ARM9 S3C2410X作為 微處理器。 例如，系統(tǒng)實時性和系統(tǒng)軟件優(yōu)化上的考慮。 高速緩存的引入是基于如下事實，即處理器速度遠遠高于存儲器訪問速度 。每一級流水都對應 CPU的一個時鐘周 期，如果一級流水中的邏輯過于復雜，使得執(zhí)行時間居高不下，必然導致所需的時鐘周期變 長，造成 CPU的主頻不能提升。采用 RISC架構(gòu)的 ARM微處理 器一般有如表 42所示的特點： 表 42 ARM CPU特點 基于以上的一些優(yōu)點，隨著更多應用在嵌入式系統(tǒng)中的實現(xiàn)，作為 32位結(jié)構(gòu)體系中的 翹楚， ARM在各種應用領(lǐng)域里得了極其廣泛的應用。 監(jiān)控系統(tǒng)中主要的硬件有：嵌入式處理器器、 Flash、 SDRAM、 網(wǎng)卡、攝像頭以及外存 儲器等。該方案中采用純軟壓縮的方 式來壓縮視頻圖像，以節(jié)約成本，但畢竟 ARM的運算能務有限，如果做 JPEG4壓縮，經(jīng) 研究認證 QCIF格式最多也只能達到 15fps， 因此我們的視頻格式采用 MJPEG視頻流格式。方案 3主要問題是 缺乏強大的圖像處理能力，不能滿足高實時性要求。一幀 320X240象素的圖像經(jīng) JPEG壓縮后，大概在 5K/幀左右，按每秒 25幀計 算，大約 125K/秒，在局域網(wǎng)10/10〇 M的通信中完全能夠滿足要求。所 以本課題中采用 MJPEG壓縮算法進 行靜態(tài)或運動圖像的壓縮及解壓縮。 MPEG4以及 ，它們壓縮倍數(shù)可達 200倍，壓縮率極高且需 要更少的帶寬。 2) 運動圖像 壓縮技術(shù)： MPEG標準、 當前研究視頻壓縮技術(shù)的國際組織主要有：國際電信聯(lián)盟 （ ITU， Internation Telemucation Union)和國際標準化組織的運動圖像專家組 (MPEG， Moving Picture Experts Group)。 JPEG標準是國際 上彩色、灰度、靜止圖像的第一個國際標準，它包括基于 DPCM(差分脈沖編碼調(diào)制、 DCT(離 散余弦變換 )和 Huffman編碼的有損壓縮算法兩個部分。 視頻數(shù)據(jù)壓縮主要基于對各種圖像數(shù)據(jù)冗余度及視覺冗余度間的壓縮，包括如下一些方 法：統(tǒng)計冗余度的壓縮、空間冗余度的壓縮、時間冗余度的壓縮、視覺冗余度的壓縮。因此，無論 是為了存儲還是傳輸視頻數(shù)據(jù)，都必須進行壓縮才具有實際意義。視頻壓縮算法利用這兩點可大幅度地壓縮數(shù)據(jù)量， 同時保證較好的主觀圖像質(zhì)量。與單播協(xié)議相比，組播沒有糾錯機制，發(fā)生丟包錯包后 難以彌補，但可以通過一定的容錯機制和 QOS加以彌補。組播是一種允許一個或多個發(fā)送者 (組播源 )發(fā)送 單一的數(shù)據(jù)包到多個 圖 36視頻傳輸?shù)膮f(xié)議架構(gòu) 13 接收者 (一次的，同時的 )的網(wǎng)絡技術(shù)。主機可以向路由器請求加入或退出某個組，網(wǎng)絡中的路由器和交換機有選擇的復制并 傳輸數(shù)據(jù)，即只將組內(nèi)數(shù)據(jù)傳輸給那些加入該組的主機。服務器針對每個客戶機發(fā)送數(shù)據(jù)流，服務器流量 =客戶機數(shù)量 x客戶機流量，在客戶機數(shù)量大、流量大的視頻應用中會造成數(shù)據(jù)冗余，消耗過多的主干網(wǎng) 絡帶寬，表現(xiàn)為服 務器響應時間延長，甚至停止響應。對于視頻多媒體數(shù)據(jù) 的傳輸來說，時間軸上的連續(xù)性要求網(wǎng)絡的實時性傳輸和高帶寬，而且視頻數(shù)據(jù)具有數(shù)據(jù)量 大又允許有一定的數(shù)據(jù)錯誤率和數(shù)據(jù)丟失率等特點，因此傳輸視頻數(shù)據(jù)實時性要求要高于可 靠性，所以在系統(tǒng)中采用建立在 UDP上的 RTP/RTCP協(xié)議對視頻流進行封裝、打包和同步 來傳輸視頻數(shù)據(jù)，可以使視頻的網(wǎng)絡傳輸延時和質(zhì)量達到最佳。例如有客戶端退出，改變顏色等指令。因此，接收端可以利用這些信息動態(tài)地改變傳輸速率，甚至改變有效載荷類型。 RTP會話期間，由于網(wǎng)絡擁塞或延時時，丟棄數(shù)據(jù)包，而數(shù)據(jù)的接收方卻仍然能夠根據(jù) 時間戳和順序號對丟失的或己混亂失序的數(shù)據(jù)包進行重新組合，使得傳輸?shù)靡匝永m(xù)而不會產(chǎn) 生過分的延遲。 RTP/RTCP協(xié)議工作流程 在具體實現(xiàn)時，可把 RTP執(zhí)行程序看成是應用程序的一部分，把 RTP集成到應用程序 中。 RTCP控制報文的發(fā)送周期是 變化的，與報文長度 L、用戶數(shù) N和控制報文帶寬 B相關(guān)：周期 P=LxN/B。 (2) 標識 (Identification)RTP數(shù)據(jù)分組只用一個隨機產(chǎn)生的 32比特標識符來標識其數(shù) 據(jù)源。由實時數(shù)據(jù)接收方發(fā)送， RR報文針對每個信 源都提供報文丟失數(shù)、已收報文的最大序列號、到達時間抖動、接收最后一個 SR的時間、 接收最后一個 SR的延遲等信息。 （ 5)APP: 應用特定函數(shù)。 RTCP報文頭部參數(shù)首先要區(qū)別攜帶不同控制信息的 RTCP報文的類型， RTCP報文的類 型主要有以下幾種： （ 1)SR:發(fā)送報告，當前活動發(fā)送者發(fā)送、接收統(tǒng)計。 1) RTCP協(xié)議數(shù)據(jù)包格式 RTP提供一個控制協(xié)議 (即 RTCP)， 用來支持其協(xié)議功能，圖 34和 35是 RTCP協(xié)議的 相關(guān)示意圖，直觀地描述了 RTcP包的打包結(jié)構(gòu)、包格式等。對于一些大的數(shù)據(jù)塊，一個數(shù)據(jù)塊被分 成多個 RTP包，它們的時間戳相同。 RTP包頭的時間戳和順序號是該協(xié)議的精華之處，其詳細解釋如下： 序列號 （ SequeneeNumber):16位長度，每發(fā)送一個 RTP數(shù)據(jù)包序列號加 1，接收方根 據(jù)此可以發(fā)現(xiàn)是否有數(shù)據(jù)包丟失。 RTP協(xié)議位于 UDP之上，在功能上獨立于下面的傳輸層 (UDP)和網(wǎng)絡層，但不能單獨作 為一個層次存在。由于 UDP是無連接的不可靠的協(xié)議，無法保證實時視頻傳輸 業(yè)務的服務質(zhì)量，為了支持網(wǎng)絡實時傳輸服務、 QOS保證等問題， 1996年 IETF(Inte Engineering Task Force)的視頻音頻工作組制訂了 RTP實時傳輸協(xié)議。相對于 TCP來說， UDP有如下優(yōu)點： 1) 時延小 ： UDP傳送數(shù)據(jù)前并不與對方建立連接，數(shù)據(jù)的傳輸不需要經(jīng)過 “三次握手 ” ， 發(fā)送完畢后也不需要釋放鏈接，因此減少了開銷和發(fā)送數(shù)據(jù)之前的時延。由此看來，由于 TCP的重傳機制和擁塞控制機制， TCP更適用于對傳輸可靠性高于實時性要求的信息傳輸。 TCP 協(xié)議 （ 傳輸控制協(xié)議 /Transpo