(攝像頭的工作原理(獲取視頻數(shù)據(jù)))攝像頭視頻采集壓縮及傳輸

1、攝像頭視頻采集壓縮及傳輸引言：攝像頭基本的功能還是視頻傳輸， 那么它是依靠怎樣的原理來實現(xiàn)的呢？所 謂視頻傳輸 : 就是將圖片一張張傳到屏幕，由于傳輸速度很快，所以可以讓大家 看到連續(xù)動態(tài)的畫面，就像放電影一樣。一般當(dāng)畫面的傳輸數(shù)量達到每秒 24 幀 時，畫面就有了連續(xù)性。下邊我們將介紹攝像頭視頻采集壓縮及傳輸?shù)恼麄€過程。 一攝像頭的工作原理（獲取視頻數(shù)據(jù)）攝像頭的工作原理大致為：景物通過鏡頭（LENS）生成的光學(xué)圖像投射到 圖像傳感器表面上，然后轉(zhuǎn)為電信號，經(jīng)過 A/D （模數(shù)轉(zhuǎn)換）轉(zhuǎn)換后變?yōu)閿?shù)字圖 像信號，再送到數(shù)字信號處理芯片（DSP）中加工處理，再通過USB接口傳輸?shù)?電腦中處理，通過

2、顯示器就可以看到圖像了。下圖是攝像頭工作的流程圖：注1:圖像傳感器（SENSOR）是一種半導(dǎo)體芯片，其表面包含有幾十萬到 幾百萬的光電二極管。光電二極管受到光照射時，就會產(chǎn)生電荷。注2:數(shù)字信號處理芯片 DSP （DIGITAL SIGNAL PROCESSING）功能：主 要是通過一系列復(fù)雜的數(shù)學(xué)算法運算， 對數(shù)字圖像信號參數(shù)進行優(yōu)化處理， 并把 處理后的信號通過USB等接口傳到PC等設(shè)備。DSP結(jié)構(gòu)框架：1. ISP （ image signal processor ）（鏡像信號處理器）2. JPEG encoder（ JPEG圖像解碼器）3. USB device controller

3、（ USB 設(shè)備控制器）而視頻要求將獲取的視頻圖像通過互聯(lián)網(wǎng)傳送到異地的電腦上顯示出來這 其中就涉及到對于獲得的視頻圖像的傳輸。在進行這種圖片的傳輸時， 必須將圖片進行壓縮， 一般壓縮方式有如 H.261 、 JPEG MPEG等，否則傳輸所需的帶寬會變得很大。 大家用RealPlayer不知是否 留意，當(dāng)播放電影的時候， 在播放器的下方會有一個傳輸速度 250kbps 、400kbps 、 1000kbps 畫面的質(zhì)量越高，這個速度也就越大。而攝像頭進行視頻傳輸也是這 個原理，如果將攝像頭的分辨率調(diào)到640X480,捕捉到的圖片每張大小約為50kb 左右，每秒30幀，那么攝像頭傳輸視頻所需的

4、速度為50X30/S = 1500kbps =1.5Mbps。而在實際生活中，人們一般用于網(wǎng)絡(luò)視頻聊天時的分辨率為 320 X240 甚至更低，傳輸?shù)膸瑪?shù)為每秒 24 幀。換言之，此時視頻傳輸速率將不到 300kbps， 人們就可以進行較為流暢的視頻傳輸聊天。如果采用更高的壓縮視頻方式，如 MPEG-1 等等，可以將傳輸速率降低到 200kbps 不到。這個就是一般視頻聊天時， 攝像頭所需的網(wǎng)絡(luò)傳輸速度。二視頻壓縮部分視頻的壓縮 是視頻處理的核心， 按照是否實時性可以分為非實時壓縮和實時 壓縮。而視頻傳輸（如 QQ 視頻即時聊天）屬于要求視頻壓縮為實時壓縮。下面 對于視頻為什么能壓縮進行說明。

5、視頻壓縮是有損壓縮， 一般說來， 視頻壓縮的壓縮率都很高， 能夠做到這么 高的壓縮率是因為視頻圖像有著非常大 的時間和空間的冗余度 。所謂的時間冗余 度指的是兩幀相鄰的圖像他們相同位置的像素值比較類似，具有很大的相關(guān)性， 尤其是靜止圖像， 甚至兩幀圖像完全相同， 對運動圖像，通過某種運算 （運動估 計），應(yīng)該說他們也具有很高的相關(guān)性； 而空間相關(guān)性指的是同一幀圖像， 相鄰 的兩個像素也具備一定的相關(guān)性。 這些相關(guān)性是視頻壓縮算法的初始假設(shè)， 換句 話說，如果不滿足這兩個條件（全白噪聲圖像，場景頻繁切換圖像等），視頻壓 縮的效果是會很差的。去除時間相關(guān)性的關(guān)鍵算法是運動估計， 它找出當(dāng)前圖像宏塊

6、在上一幀圖像 中最匹配的位置， 很多時候， 我們只需要把這個相對坐標記錄下來， 就夠了，這 樣就節(jié)省了大量碼字， 提高了壓縮率。 視頻壓縮算法中， 運動估計永遠是最關(guān)鍵 最核心的部分。去除空間相關(guān)性是通過 DCT 變換來實現(xiàn)的，把時域上的數(shù)據(jù)映 射到頻域上，然后對 DCT 系數(shù)進行量化處理，基本上，所有的有損壓縮，都會 有量化，它提高壓縮率最明顯。圖像的原始文件是比較大的， 必須經(jīng)過圖像壓縮才能夠進行快速的傳輸以及 順暢的播放。 而壓縮比正是來衡量影像壓縮大小的參數(shù)。 一般來說， 攝像頭的壓 縮比率大都是 5:1 。也就是說，如果在未壓縮之前 30 秒的圖像的容量是 30MB， 那么按照攝像頭

7、 5:1 的壓縮比率來對圖像進行壓縮以后， 它的大小就變成了 6MB 了。主要的視頻壓縮算法包括： M-JPEG、Mpeg、H.264、Wavelet （小波壓縮）、 JPEG 2000、 AVS?；旧弦曨l壓縮的核心就這些。三視頻傳輸部分為了保證數(shù)字視頻網(wǎng)絡(luò)傳輸?shù)膶崟r性和圖像的質(zhì)量， 傳輸層協(xié)議的選擇是整 個設(shè)計和實現(xiàn)的關(guān)鍵。In ternet在IP層上使用兩種傳輸協(xié)議：一種是 TCP（傳輸控制協(xié)議），它是面向連接的網(wǎng)絡(luò)協(xié)議；另一種是UDP（用戶數(shù)據(jù)報協(xié)議），它是無連接的網(wǎng)絡(luò)協(xié)議。TCP傳輸：TCP （傳輸控制協(xié)議）是一種面向連接的網(wǎng)絡(luò)傳輸協(xié)議。支持多 數(shù)據(jù)流操作， 提供流控和錯誤控制， 乃

8、至對亂序到達報文的重新排序， 因此， TCP 傳輸提供了可靠的數(shù)據(jù)傳輸服務(wù)。使用 TCP 傳輸?shù)囊话愕倪^程：客戶機向服務(wù)器發(fā)出連接的請求后，服務(wù)器接收 到后，向客戶機發(fā)出連接確認，實現(xiàn)連接后，雙方進行數(shù)據(jù)傳輸。UDP傳輸：UDP （用戶數(shù)據(jù)報協(xié)議）是一種無連接的網(wǎng)絡(luò)傳輸協(xié)議。提供 一種基本的低延時的稱謂數(shù)據(jù)報的傳輸服務(wù)。不需要像 TCP 傳輸一樣需預(yù)先建 立一條連接。 UDP 無計時機制、流控或擁塞管理機制。丟失的數(shù)據(jù)不會重傳。 因此提供一種不可靠的的應(yīng)用數(shù)據(jù)傳輸服務(wù)。 但在一個良好的網(wǎng)絡(luò)環(huán)境下如局域 網(wǎng)內(nèi)，使用 UDP 傳輸數(shù)據(jù)還是比較可靠，且效率很高。IP 組播技術(shù)： 組播技術(shù)是一種允許一

9、個或多個發(fā)送者發(fā)送單一或多個發(fā)送 者的數(shù)據(jù)包到多個接收者的網(wǎng)絡(luò)技術(shù)。 組播源把數(shù)據(jù)報發(fā)送到特定的組播組， 而 只有加入到該組播組的主機才能接收到這些數(shù)據(jù)包。組播可大大節(jié)省網(wǎng)絡(luò)寬帶， 因為無論有多少個目標地址，在整個網(wǎng)絡(luò)的任何一條鏈路上只船送單一的數(shù)據(jù) 包。1.TCP/IP 協(xié)議和實時傳輸TCP/IP 協(xié)議最初是為提供非實時數(shù)據(jù)業(yè)務(wù)而設(shè)計的。 IP 協(xié)議負責(zé)主機之間 的數(shù)據(jù)傳輸， 不進行檢錯和糾錯。 因此，經(jīng)常發(fā)生數(shù)據(jù)丟失或失序現(xiàn)象。 為保證 數(shù)據(jù)的可靠傳輸，人們將TCP協(xié)議用于IP數(shù)據(jù)的傳輸，以提高接收端的檢錯和 糾錯能力。 當(dāng)檢測到數(shù)據(jù)包丟失或錯誤時， 就會要求發(fā)送端重新發(fā)送， 這樣一來 就

10、不可避免地引起了傳輸延時和耗用網(wǎng)絡(luò)的帶寬。因此傳統(tǒng)的 TCP/IP 協(xié)議傳輸 實時音頻、視頻數(shù)據(jù)的能力較差。 當(dāng)然在傳輸用于回放的視頻和音頻數(shù)據(jù)時， TCP 協(xié)議也是一種選擇。如果有足夠大的緩沖區(qū)、充足的網(wǎng)絡(luò)帶寬，在 TCP 協(xié)議上， 接近實時的視音頻傳輸也是可能的。 然而， 如果在丟包率較高、 網(wǎng)絡(luò)狀況不好的 情況下，利用 TCP 協(xié)議進行視頻或音頻通信幾乎是不可能的。TCP和其它可靠的傳輸層協(xié)議如XTP不適合實時視音頻傳輸?shù)脑蛑饕幸?下幾個方面：1 .TCP 的重傳機制我們知道，在 TCP/IP 協(xié)議中，當(dāng)發(fā)送方發(fā)現(xiàn)數(shù)據(jù)丟失時，它將要求重傳丟 失的數(shù)據(jù)包。 然而這將需要一個甚至更多的周

11、期 （根據(jù) TCP/IP 的快速重傳機制， 這將需要三個額外的幀延遲） ，這種重傳對于實時性要求較高的視音頻數(shù)據(jù)通信來說幾乎是災(zāi)難性的， 因為接收方不得不等待重傳數(shù)據(jù)的到來， 從而造成了延遲 和斷點(音頻的不連續(xù)或視頻的凝固等等)。2 .TCP 的擁塞控制機制TCP 的擁塞控制機制在探測到有數(shù)據(jù)包丟失時，它就會減小它的擁塞窗口。 而另一方面，音頻、視頻在特定的編碼方式下，產(chǎn)生的編碼數(shù)量(即碼率)是不 可能突然改變的。 正確的擁塞控制應(yīng)該是變換音頻、 視頻信息的編碼方式， 調(diào)節(jié) 視頻信息的幀頻或圖像幅面的大小等等。3 .TCP 報文頭的大小TCP不適合于實時視音頻傳輸?shù)牧硪粋€缺陷是，它的報文頭比

12、UDP的報文頭大。TCP的報文頭為40個字節(jié)，而UDP的報文頭僅為12個字節(jié)。并且，這些 可靠的傳輸層協(xié)議不能提供時間戳( Time Stamp )和編解碼信息( Encoding Information )，而這些信息恰恰是接收方(即客戶端)的應(yīng)用程序所需要的。 因此 TCP 是不適合于視音頻信息的實時傳輸?shù)摹? . 啟動速度慢即便是在網(wǎng)絡(luò)運行狀態(tài)良好、沒有丟包的情況下，由于 TCP 的啟動需要建 立連接， 因而在初始化的過程中， 需要較長的時間， 而在一個實時視音頻傳輸應(yīng) 用中，盡量少的延遲正是我們所期望的。由此可見， TCP 協(xié)議是不適合用來傳輸實時視音頻數(shù)據(jù)的， 為了實現(xiàn)視音頻 數(shù)據(jù)的

13、實時傳輸，我們需要尋求其它的途徑。2.RTP 協(xié)議適合實時視音頻傳輸RTP(Real-Time Transport Protocol )/RTCP(Real-Time Transport Control Protocol )是一種應(yīng)用型的傳輸層協(xié)議，它并不提供任何傳輸可靠性的保證和流 量的擁塞控制機制。它是由 IETF(Internet Engineering Task Force )為視音頻 的實時傳輸而設(shè)計的傳輸協(xié)議。RTP協(xié)議位于UDP協(xié)議之上，在功能上獨立于 下面的傳輸層(UDP)和網(wǎng)絡(luò)層，但不能單獨作為一個層次存在，通常是利用低 層的 UDP 協(xié)議對實時視音頻數(shù)據(jù)進行組播( Mult

14、icast )或單播( Unicast ),從而 實現(xiàn)多點或單點視音頻數(shù)據(jù)的傳輸。UDP 是一種無連接的數(shù)據(jù)報投遞服務(wù)，雖然沒有 TCP 那么可靠，并且無法 保證實時視音頻傳輸業(yè)務(wù)的服務(wù)質(zhì)量 (QoS),需要RTCP實時監(jiān)控數(shù)據(jù)傳輸和服 務(wù)質(zhì)量，但是，由于UDP的傳輸延時低于TCP，能與音頻和視頻流很好地匹配。 因此，在實際應(yīng)用中， RTP/RTCP/UDP 用于音視頻媒體，而 TCP 用于數(shù)據(jù)和控 制信令的傳輸?？偨Y(jié) ：如果接收端和發(fā)送端處于同一個局域網(wǎng)內(nèi)，由于有充分的帶寬保證， 在滿足視頻傳輸?shù)膶崟r性方面， TCP 也可以有比較好的表現(xiàn)， TCP 和基于 UDP 的 RTP 的視頻傳輸性能相差不大。由于在局域網(wǎng)內(nèi)帶寬不是主要矛盾，此時視 頻數(shù)據(jù)傳輸所表現(xiàn)出來的延時主要體現(xiàn)為處理延時， 它是由處理機的處理能力以 及采用的處理機制所決定的 。但是當(dāng)在廣域網(wǎng)中進行視頻數(shù)據(jù)傳輸時，此時的 傳輸性能極大地取決于可用的帶寬，由于 TCP 是面向連接的傳輸層協(xié)議，它的 重傳機制和擁塞控制機制，將使網(wǎng)絡(luò)狀況進一步惡化，從而帶來災(zāi)難性的延時。 同時，在這種網(wǎng)絡(luò)環(huán)境下，通過 TCP 傳輸?shù)囊曨l數(shù)據(jù)，在接收端重建、回放時， 斷點非常明顯，體現(xiàn)為明顯的斷斷續(xù)續(xù)，傳輸?shù)膶崟r性和傳輸質(zhì)量都無法保障。 相對而言，采用 RTP 傳輸?shù)囊曨l數(shù)據(jù)的實時性和傳輸質(zhì)量就要好得多。 四視頻圖像的異地顯示 當(dāng)