【正文】 數(shù)字視頻傳輸?shù)膶崟r性和圖像的質(zhì)量，傳輸層協(xié)議的選擇是整個設(shè)計和實現(xiàn) 的關(guān)鍵關(guān)鍵之一。無連接服務(wù)是郵政系統(tǒng)服務(wù)的抽象。 2) RTCP協(xié)議 (實時傳輸控制協(xié)議 )，用來控 制服務(wù)質(zhì)量。 時間戳 (Timestamp):犯位長度，是實時數(shù)據(jù)傳輸?shù)闹匾畔?，它記錄了?shù)據(jù)塊第一字節(jié) 的 采樣時間，采樣時間是線性單調(diào)增長的，其時鐘頻率取決于 RTP幀的載荷類型。s cumulative byte count 圖 34 RTCP發(fā)送報告包頭格式 0 12 3 ~ 0 i 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 f Y 3 4—567 V=2 P RR count 錢荷類型 (PT Message length _____________________SSRC of report sender ___________________________ SSRC of first source head from — __ RTP timestamp fraction lost Cumulative number of lost packets Extended 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 圖 35 RTCP接收報告包頭格式 類似于 RTP數(shù)據(jù)包，每個 RTCP報文以固定的包頭部分開始，緊接著的是可變長結(jié)構(gòu)元 素，類型不同長度也不同，但 總是 32位的整數(shù)倍，長度在固定部分的長度域中標(biāo)明。由處于活躍狀態(tài)的信源發(fā)送方發(fā)送， SR報文不 僅提供該端系統(tǒng)作為接收方的數(shù)據(jù)接收質(zhì)量反饋信息，而且還提供 SSRC(同步源 )標(biāo)識符、 RTP時間戮、發(fā)送包數(shù)以及發(fā)送字節(jié)數(shù)等與發(fā)送有關(guān)的信息。 (3) 根據(jù)與會者的數(shù)量來調(diào)整 RTCP包的發(fā)送率。 在應(yīng)用 RTP會話時會使 用兩個端口，一個給 RTP， 一個給 RTCP。根據(jù)用戶間的數(shù)據(jù)傳輸反饋信息，可以制定流量控制的策略，而會 話用戶信息的交互，可以制定會話控制的策略。 由上面分析可知，視頻傳輸所需協(xié)議的整體架構(gòu)如圖 36所示： 當(dāng)前的網(wǎng)絡(luò)中有三種通訊模式：單播、廣播、組播 (多播 )。 相對于單播、廣播比較而一言，組播技術(shù)有其獨特的優(yōu)越性。 法的分析選擇 數(shù)字視頻信號的數(shù)據(jù)大，必須對其進行壓縮才能節(jié)省存儲設(shè)備，才能有效利用信道帶寬。再者視頻圖像中間存在著大量的冗余信息，如果去掉 這些冗余信息，也就達到壓縮目的 。它不僅適14 合用于靜態(tài)圖像的壓縮，也可對連續(xù)運動圖像進行壓縮； JPEG200〇 采用的壓縮方法是小波變換的壓縮方法，處理較容易，可獲得比 JPEG更大的壓 縮，但是目前的標(biāo)準(zhǔn)還不是很統(tǒng)一； MJPEG全名為 “MotionJPEG”， MJPEG的壓縮算法與 JPEG 一脈相承，采用幀內(nèi)處理技術(shù)，主要優(yōu)點是因此每一幀都容易編輯、圖片質(zhì)量清晰等。由于 MPEG4算法 復(fù)雜，硬件完全實現(xiàn)不客易，在現(xiàn)階段的 MPEG4產(chǎn)品中普遍使用的是一些改良的基于窄帶 傳輸?shù)膲嚎s技術(shù)，所以很大程度上還存在著圖像干擾及畫面失真的情況，而且在 ARM嵌入 式系統(tǒng)上用純軟件 MPEG4方法也不會有好的效果。 15 目前常見的方案優(yōu)缺點如表 41所示： 根據(jù)上面的方案比較，對于網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)來說，方案 1由于沒有強大的操作系統(tǒng)和 網(wǎng)絡(luò)協(xié)議棧，因此不太適合做網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng) 。 嵌入式平臺硬件設(shè)備是整個監(jiān)控系統(tǒng)的基礎(chǔ)，在系統(tǒng)設(shè)計中占有至關(guān)重要的位置，硬件 的選擇成功與否直接決定著系統(tǒng)功能的優(yōu)劣，如果不適合，不但浪費了財力和物力，更是耽 誤了整個項目的進度。但 ARM9代表了 ARM公司主流的處理器，得到了更多的應(yīng)用。高速緩存正是用來解決這個問題，它可以存儲最近常用的代碼和數(shù)據(jù)，以 最快的速 度提供給 CPU處理 (CPU訪問 Cache不需要等待 )。 Flash 的選擇 目前市場上的 Flash有兩種 ： NOR Flash和 NAND Flash， 這兩種 Flash各有特點，從以 下幾方面進行比較： 性能比較 Flash閃存是非易失存儲器，可以對稱為塊的存儲器單元塊進行擦寫和再編程。 網(wǎng)卡的選擇主要考慮它的傳輸速率和芯片的通用性，因此系統(tǒng)中的網(wǎng)卡芯片采用了 DM9000以太網(wǎng)控制器，該網(wǎng)卡是 10/10oMbPs自適應(yīng)通信速率的，經(jīng)過前面的計算能夠滿 足我們的需求，而且該網(wǎng)卡芯片驅(qū)動在 ，只需要稍作修改就可 以正常運行起來。 硬盤接口使硬盤與主機系統(tǒng)間的連接部件，作用是在硬盤緩存和主機內(nèi)存之間傳輸數(shù)據(jù)。 五、硬件平臺設(shè)計 圖 51系統(tǒng)硬件結(jié)構(gòu)圖 如圖 51所示為智能家居系統(tǒng)的硬件結(jié)構(gòu)圖。 BANK0可以設(shè)置為 16位、 32位訪問； ? 8個地址空間中， 6個地址空間可以用于 ROM、 SRAM等存儲器， 2個用于 ROM、 SRAM、SDRAM等存儲器 。 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。 過外部 nWAIT引腳來延長 nOE持續(xù)時間。21 圖 521為 S3C2410復(fù)位后的存儲器地址分配圖。 ?存儲設(shè)備：存儲設(shè)備主要包括了 SDRAM、 NANDFLASH和 NORFLASH。從整體的角度上，硬盤接口分為 SCSI、 USB、 IDE、 SATA和光纖通道五種。但兩種傳感器各有特點。NAND器件執(zhí)行擦除操作是十分簡單的，而 NOR則要求在進行擦 除前先要將目標(biāo)塊內(nèi)所有的位都寫為 0。 例如，系統(tǒng)實時性和系統(tǒng)軟件優(yōu)化上的考慮。每一級流水都對應(yīng) CPU的一個時鐘周 期，如果一級流水中的邏輯過于復(fù)雜，使得執(zhí)行時間居高不下，必然導(dǎo)致所需的時鐘周期變 長，造成 CPU的主頻不能提升。 監(jiān)控系統(tǒng)中主要的硬件有：嵌入式處理器器、 Flash、 SDRAM、 網(wǎng)卡、攝像頭以及外存 儲器等。方案 3主要問題是 缺乏強大的圖像處理能力，不能滿足高實時性要求。所 以本課題中采用 MJPEG壓縮算法進 行靜態(tài)或運動圖像的壓縮及解壓縮。 2) 運動圖像 壓縮技術(shù)： MPEG標(biāo)準(zhǔn)、 當(dāng)前研究視頻壓縮技術(shù)的國際組織主要有：國際電信聯(lián)盟 （ ITU， Internation Telemucation Union)和國際標(biāo)準(zhǔn)化組織的運動圖像專家組 (MPEG， Moving Picture Experts Group)。 視頻數(shù)據(jù)壓縮主要基于對各種圖像數(shù)據(jù)冗余度及視覺冗余度間的壓縮，包括如下一些方 法：統(tǒng)計冗余度的壓縮、空間冗余度的壓縮、時間冗余度的壓縮、視覺冗余度的壓縮。視頻壓縮算法利用這兩點可大幅度地壓縮數(shù)據(jù)量， 同時保證較好的主觀圖像質(zhì)量。組播是一種允許一個或多個發(fā)送者 (組播源 )發(fā)送 單一的數(shù)據(jù)包到多個 圖 36視頻傳輸?shù)膮f(xié)議架構(gòu) 13 接收者 (一次的，同時的 )的網(wǎng)絡(luò)技術(shù)。服務(wù)器針對每個客戶機發(fā)送數(shù)據(jù)流，服務(wù)器流量 =客戶機數(shù)量 x客戶機流量，在客戶機數(shù)量大、流量大的視頻應(yīng)用中會造成數(shù)據(jù)冗余，消耗過多的主干網(wǎng) 絡(luò)帶寬，表現(xiàn)為服 務(wù)器響應(yīng)時間延長，甚至停止響應(yīng)。例如有客戶端退出，改變顏色等指令。 RTP會話期間，由于網(wǎng)絡(luò)擁塞或延時時，丟棄數(shù)據(jù)包，而數(shù)據(jù)的接收方卻仍然能夠根據(jù) 時間戳和順序號對丟失的或己混亂失序的數(shù)據(jù)包進行重新組合，使得傳輸?shù)靡匝永m(xù)而不會產(chǎn) 生過分的延遲。 RTCP控制報文的發(fā)送周期是 變化的，與報文長度 L、用戶數(shù) N和控制報文帶寬 B相關(guān)：周期 P=LxN/B。由實時數(shù)據(jù)接收方發(fā)送， RR報文針對每個信 源都提供報文丟失數(shù)、已收報文的最大序列號、到達時間抖動、接收最后一個 SR的時間、 接收最后一個 SR的延遲等信息。 RTCP報文頭部參數(shù)首先要區(qū)別攜帶不同控制信息的 RTCP報文的類型， RTCP報文的類 型主要有以下幾種： （ 1)SR:發(fā)送報告，當(dāng)前活動發(fā)送者發(fā)送、接收統(tǒng)計。對于一些大的數(shù)據(jù)塊，一個數(shù)據(jù)塊被分 成多個 RTP包，它們的時間戳相同。 RTP協(xié)議位于 UDP之上，在功能上獨立于下面的傳輸層 (UDP)和網(wǎng)絡(luò)層，但不能單獨作 為一個層次存在。相對于 TCP來說， UDP有如下優(yōu)點： 1) 時延小 ： UDP傳送數(shù)據(jù)前并不與對方建立連接，數(shù)據(jù)的傳輸不需要經(jīng)過 “三次握手 ” ， 發(fā)送完畢后也不需要釋放鏈接，因此減少了開銷和發(fā)送數(shù)據(jù)之前的時延。 TCP 協(xié)議 （ 傳輸控制協(xié)議 /Transport Control Protocol) 圖 31基本視頻網(wǎng)絡(luò)傳輸系統(tǒng) 8 TCP/IP協(xié)議最初是為非實時數(shù)據(jù)業(yè)務(wù)而設(shè)計的。因此，在有效利用現(xiàn) 有網(wǎng)絡(luò)資源基礎(chǔ)上，為了能提供較好的視頻傳輸質(zhì)量，采用何種網(wǎng)絡(luò)傳輸協(xié)議是解決該問題 的關(guān)鍵所在；數(shù)字視頻的海量信息，如果不經(jīng)過壓縮，將會浪費大量的資源，甚至造成系統(tǒng) 毫無意義。 4) 為了提高執(zhí)行速度和系統(tǒng)可靠性，嵌入式系統(tǒng)中的軟件一般都固化在存儲器芯片中，而不是 存貯于磁盤等載體中。 3) 嵌入式系統(tǒng)要求對軟硬件可以裁減，以適合各種需求。另外在 Linux下有很多優(yōu)秀的 Web服務(wù)器，如 Boa， 我們僅需移植到 EduKitIV平臺上。這樣我們就可以通過瀏覽器訪問網(wǎng)關(guān)服務(wù)器，來得到攝 像機以及其它設(shè)備的信息。 系統(tǒng)的主體設(shè)計思想是將視頻前端和嵌入式 Web服務(wù)器整合在一起，攝像頭傳送來的視頻信號 經(jīng)過壓縮后，通過內(nèi)部總線傳送到內(nèi)置的 Web服務(wù)器。 2) DSP處理器 +嵌入式處理器。 目前，國內(nèi)外對基于嵌入式網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)的研究，一般集中于嵌入式視頻監(jiān)控系統(tǒng)的設(shè)計、 嵌入式操作系統(tǒng) 的研究、視頻圖像的網(wǎng)絡(luò)傳輸以及視頻圖像處理等幾個方面。 而在這 2， 000萬臺中，超過 1， 500萬臺是 2021年出售的。計算機技術(shù) 和多媒體技術(shù)的迅速發(fā)展，以及自動控制和多媒體技術(shù)也融入到視頻監(jiān)控系統(tǒng)中，監(jiān)控技術(shù)也得到 了迅速發(fā)展。 ................................................... 12 視頻數(shù)據(jù)傳輸方式的選擇 . ................................................. 13 圖像壓縮算法的分析選擇 ............................................................................................... 13 壓縮的必要性和可能性 . ................................................... 13 系統(tǒng)視頻壓縮方法的選擇 ................................................... 14 四、監(jiān)控系統(tǒng)方案設(shè) 計 ......................................................... 15 監(jiān)控系統(tǒng)總體方案選擇 ................................................................................................... 15 監(jiān)控系統(tǒng)硬件方案設(shè)計 ................................................................................................... 16 嵌入式處理器的選擇 ..................................................... 16 Flash 的選擇 ........................................................... 18 網(wǎng)卡的選擇 . ............................................................ 18 攝像頭的選擇 .......................................................... 18 存儲硬盤接口的選擇 ..................................................... 19 五、硬件平臺設(shè) 計 ............................................................. 20 ............................................................................