攝像頭視頻采集壓縮及傳輸原理.doc

攝像頭視頻采集壓縮及傳輸原理 攝像頭基本的功能還是視頻傳輸，那么它是依靠怎樣的原理來(lái)實(shí)現(xiàn)的呢？所謂視頻傳輸:就是將圖片一張張傳到屏幕，由于傳輸速度很快，所以可以讓大家看到連續(xù)動(dòng)態(tài)的畫(huà)面，就像放電影一樣。一般當(dāng)畫(huà)面的傳輸數(shù)量達(dá)到每秒24幀時(shí)，畫(huà)面就有了連續(xù)性。下邊我們將介紹攝像頭視頻采集壓縮及傳輸?shù)恼麄€(gè)過(guò)程。一攝像頭的工作原理（獲取視頻數(shù)據(jù)）攝像頭的工作原理大致為：景物通過(guò)鏡頭（LENS）生成的光學(xué)圖像投射到圖像傳感器表面上，然后轉(zhuǎn)為電信號(hào)，經(jīng)過(guò)A/D（模數(shù)轉(zhuǎn)換）轉(zhuǎn)換后變?yōu)閿?shù)字圖像信號(hào)，再送到數(shù)字信號(hào)處理芯片（DSP）中加工處理，再通過(guò)USB接口傳輸?shù)诫娔X中處理，通過(guò)顯示器就可以看到圖像了。下圖是攝像頭工作的流程圖： 注1：圖像傳感器（SENSOR）是一種半導(dǎo)體芯片，其表面包含有幾十萬(wàn)到幾百萬(wàn)的光電二極管。光電二極管受到光照射時(shí)，就會(huì)產(chǎn)生電荷。 注2：數(shù)字信號(hào)處理芯片DSP（DIGITAL SIGNAL PROCESSING）功能：主要是通過(guò)一系列復(fù)雜的數(shù)學(xué)算法運(yùn)算，對(duì)數(shù)字圖像信號(hào)參數(shù)進(jìn)行優(yōu)化處理，并把處理后的信號(hào)通過(guò)USB等接口傳到PC等設(shè)備。 DSP結(jié)構(gòu)框架: 1. ISP（image signal processor）（鏡像信號(hào)處理器） 2. JPEG encoder（JPEG圖像解碼器） 3. USB device controller（USB設(shè)備控制器） 而視頻要求將獲取的視頻圖像通過(guò)互聯(lián)網(wǎng)傳送到異地的電腦上顯示出來(lái)這其中就涉及到對(duì)于獲得的視頻圖像的傳輸。在進(jìn)行這種圖片的傳輸時(shí)，必須將圖片進(jìn)行壓縮，一般壓縮方式有如H.261、JPEG、MPEG等，否則傳輸所需的帶寬會(huì)變得很大。大家用RealPlayer不知是否留意，當(dāng)播放電影的時(shí)候，在播放器的下方會(huì)有一個(gè)傳輸速度250kbps、400kbps、1000kbps畫(huà)面的質(zhì)量越高，這個(gè)速度也就越大。而攝像頭進(jìn)行視頻傳輸也是這個(gè)原理，如果將攝像頭的分辨率調(diào)到640480，捕捉到的圖片每張 大小約為50kb左右，每秒30幀，那么攝像頭傳輸視頻所需的速度為5030/s1500kbps1.5Mbps。而在實(shí)際生活中，人們一般用于網(wǎng)絡(luò)視頻聊天時(shí)的分辨率為320240甚至更低，傳輸?shù)膸瑪?shù)為每秒24幀。換言之，此時(shí)視頻傳輸速率將不到300kbps，人們就可以進(jìn)行較為流暢的視頻傳輸聊天。如果采用更高的壓縮視頻方式，如MPEG-1等等，可以將傳輸速率降低到200kbps不到。這個(gè)就是一般視頻聊天時(shí)，攝像頭所需的網(wǎng)絡(luò)傳輸速度。二視頻壓縮部分視頻的壓縮是視頻處理的核心，按照是否實(shí)時(shí)性可以分為非實(shí)時(shí)壓縮和實(shí)時(shí)壓縮。而視頻傳輸（如QQ視頻即時(shí)聊天）屬于要求視頻壓縮為實(shí)時(shí)壓縮。下面對(duì)于視頻為什么能壓縮進(jìn)行說(shuō)明。視頻壓縮是有損壓縮，一般說(shuō)來(lái)，視頻壓縮的壓縮率都很高，能夠做到這么高的壓縮率是因?yàn)橐曨l圖像有著非常大的時(shí)間和空間的冗余度。所謂的時(shí)間冗余度指的是兩幀相鄰的圖像他們相同位置的像素值比較類(lèi)似，具有很大的相關(guān)性，尤其是靜止圖像，甚至兩幀圖像完全相同，對(duì)運(yùn)動(dòng)圖像，通過(guò)某種運(yùn)算（運(yùn)動(dòng)估計(jì)），應(yīng)該說(shuō)他們也具有很高的相關(guān)性；而空間相關(guān)性指的是同一幀圖像，相鄰的兩個(gè)像素也具備一定的相關(guān)性。這些相關(guān)性是視頻壓縮算法的初始假設(shè)，換句話(huà)說(shuō)，如果不滿(mǎn)足這兩個(gè)條件（全白噪聲圖像，場(chǎng)景頻繁切換圖像等），視頻壓縮的效果是會(huì)很差的。去除時(shí)間相關(guān)性的關(guān)鍵算法是運(yùn)動(dòng)估計(jì)，它找出當(dāng)前圖像宏塊在上一幀圖像中最匹配的位置，很多時(shí)候，我們只需要把這個(gè)相對(duì)坐標(biāo)記錄下來(lái)，就夠了，這樣就節(jié)省了大量碼字，提高了壓縮率。視頻壓縮算法中，運(yùn)動(dòng)估計(jì)永遠(yuǎn)是最關(guān)鍵最核心的部分。去除空間相關(guān)性是通過(guò)DCT變換來(lái)實(shí)現(xiàn)的，把時(shí)域上的數(shù)據(jù)映射到頻域上，然后對(duì)DCT系數(shù)進(jìn)行量化處理，基本上，所有的有損壓縮，都會(huì)有量化，它提高壓縮率最明顯。圖像的原始文件是比較大的，必須經(jīng)過(guò)圖像壓縮才能夠進(jìn)行快速的傳輸以及順暢的播放。而壓縮比正是來(lái)衡量影像壓縮大小的參數(shù)。一般來(lái)說(shuō)，攝像頭的壓縮比率大都是5:1。也就是說(shuō)，如果在未壓縮之前30秒的圖像的容量是30MB，那么按照攝像頭5:1的壓縮比率來(lái)對(duì)圖像進(jìn)行壓縮以后，它的大小就變成了6MB了。主要的視頻壓縮算法包括：M-JPEG、Mpeg、H.264、Wavelet（小波壓縮）、JPEG 2000、AVS?；旧弦曨l壓縮的核心就這些。三視頻傳輸部分為了保證數(shù)字視頻網(wǎng)絡(luò)傳輸?shù)膶?shí)時(shí)性和圖像的質(zhì)量，傳輸層協(xié)議的選擇是整個(gè)設(shè)計(jì)和實(shí)現(xiàn)的關(guān)鍵。Internet在IP層上使用兩種傳輸協(xié)議：一種是TCP(傳輸控制協(xié)議)，它是面向連接的網(wǎng)絡(luò)協(xié)議；另一種是UDP(用戶(hù)數(shù)據(jù)報(bào)協(xié)議)，它是無(wú)連接的網(wǎng)絡(luò)協(xié)議。TCP傳輸：TCP（傳輸控制協(xié)議）是一種面向連接的網(wǎng)絡(luò)傳輸協(xié)議。支持多數(shù)據(jù)流操作，提供流控和錯(cuò)誤控制，乃至對(duì)亂序到達(dá)報(bào)文的重新排序，因此，TCP傳輸提供了可靠的數(shù)據(jù)傳輸服務(wù)。使用TCP傳輸?shù)囊话愕倪^(guò)程：客戶(hù)機(jī)向服務(wù)器發(fā)出連接的請(qǐng)求后，服務(wù)器接收到后，向客戶(hù)機(jī)發(fā)出連接確認(rèn)，實(shí)現(xiàn)連接后，雙方進(jìn)行數(shù)據(jù)傳輸。UDP傳輸： UDP（用戶(hù)數(shù)據(jù)報(bào)協(xié)議）是一種無(wú)連接的網(wǎng)絡(luò)傳輸協(xié)議。提供一種基本的低延時(shí)的稱(chēng)謂數(shù)據(jù)報(bào)的傳輸服務(wù)。不需要像TCP傳輸一樣需預(yù)先建立一條連接。UDP無(wú)計(jì)時(shí)機(jī)制、流控或擁塞管理機(jī)制。丟失的數(shù)據(jù)不會(huì)重傳。因此提供一種不可靠的的應(yīng)用數(shù)據(jù)傳輸服務(wù)。但在一個(gè)良好的網(wǎng)絡(luò)環(huán)境下如 局域網(wǎng)內(nèi)，使用UDP傳輸數(shù)據(jù)還是比較可靠，且效率很高。IP組播技術(shù)：組播技術(shù)是一種允許一個(gè)或多個(gè)發(fā)送者發(fā)送單一或多個(gè)發(fā)送者的數(shù)據(jù)包到多個(gè)接收者的網(wǎng)絡(luò)技術(shù)。組播源把數(shù)據(jù)報(bào)發(fā)送到特定的組播組，而只有加入到該組播組的主機(jī)才能接收到這些數(shù)據(jù)包。組播可大大節(jié)省網(wǎng)絡(luò)寬帶，因?yàn)闊o(wú)論有多少個(gè)目標(biāo)地址，在整個(gè)網(wǎng)絡(luò)的任何一條鏈路上只船送單一的數(shù)據(jù)包。1.TCP/IP協(xié)議和實(shí)時(shí)傳輸TCP/IP協(xié)議最初是為提供非實(shí)時(shí)數(shù)據(jù)業(yè)務(wù)而設(shè)計(jì)的。IP協(xié)議負(fù)責(zé)主機(jī)之間的數(shù)據(jù)傳輸，不進(jìn)行檢錯(cuò)和糾錯(cuò)。因此，經(jīng)常發(fā)生數(shù)據(jù)丟失或失序現(xiàn)象。為保證數(shù)據(jù)的可靠傳輸，人們將TCP協(xié)議用于IP數(shù)據(jù)的傳輸，以提高接收端的檢錯(cuò)和糾錯(cuò)能力。當(dāng)檢測(cè)到數(shù)據(jù)包丟失或錯(cuò)誤時(shí)，就會(huì)要求發(fā)送端重新發(fā)送，這樣一來(lái)就不可避免地引起了傳輸延時(shí)和耗用網(wǎng)絡(luò)的帶寬。因此傳統(tǒng)的TCP/IP協(xié)議傳輸實(shí)時(shí)音頻、視頻數(shù)據(jù)的能力較差。當(dāng)然在傳輸用于回放的視頻和音頻數(shù)據(jù)時(shí)，TCP協(xié)議也是一種選擇。如果有足夠大的緩沖區(qū)、充足的網(wǎng)絡(luò)帶寬，在TCP協(xié)議上，接近實(shí)時(shí)的視音頻傳輸也是可能的。然而，如果在丟包率較高、網(wǎng)絡(luò)狀況不好的情況下，利用TCP協(xié)議進(jìn)行視頻或音頻通信幾乎是不可能的。 TCP和其它可靠的傳輸層協(xié)議如XTP不適合實(shí)時(shí)視音頻傳輸?shù)脑蛑饕幸韵聨讉€(gè)方面： 1 .TCP的重傳機(jī)制 我們知道，在TCP/IP協(xié)議中，當(dāng)發(fā)送方發(fā)現(xiàn)數(shù)據(jù)丟失時(shí)，它將要求重傳丟失的數(shù)據(jù)包。然而這將需要一個(gè)甚至更多的周期（根據(jù)TCP/IP的快速重傳機(jī)制，這將需要三個(gè)額外的幀延遲），這種重傳對(duì)于實(shí)時(shí)性要求較高的視音頻數(shù)據(jù)通信來(lái)說(shuō)幾乎是災(zāi)難性的，因?yàn)榻邮辗讲坏貌坏却貍鲾?shù)據(jù)的到來(lái)，從而造成了延遲和斷點(diǎn)（音頻的不連續(xù)或視頻的凝固等等）。 2 .TCP的擁塞控制機(jī)制 TCP的擁塞控制機(jī)制在探測(cè)到有數(shù)據(jù)包丟失時(shí)，它就會(huì)減小它的擁塞窗口。而另一方面，音頻、視頻在特定的編碼方式下，產(chǎn)生的編碼數(shù)量（即碼率）是不可能突然改變的。正確的擁塞控制應(yīng)該是變換音頻、視頻信息的編碼方式，調(diào)節(jié)視頻信息的幀頻或圖像幅面的大小等等。 3 .TCP報(bào)文頭的大小 TCP不適合于實(shí)時(shí)視音頻傳輸?shù)牧硪粋€(gè)缺陷是，它的報(bào)文頭比UDP的報(bào)文頭大。TCP的報(bào)文頭為40個(gè)字節(jié)，而UDP的報(bào)文頭僅為12個(gè)字節(jié)。并且，這些可靠的傳輸層協(xié)議不能提供時(shí)間戳（Time Stamp）和編解碼信息（Encoding Information），而這些信息恰恰是接收方（即客戶(hù)端）的應(yīng)用程序所需要的。因此TCP是不適合于視音頻信息的實(shí)時(shí)傳輸?shù)摹?4 .啟動(dòng)速度慢 即便是在網(wǎng)絡(luò)運(yùn)行狀態(tài)良好、沒(méi)有丟包的情況下，由于TCP的啟動(dòng)需要建立連接，因而在初始化的過(guò)程中，需要較長(zhǎng)的時(shí)間，而在一個(gè)實(shí)時(shí)視音頻傳輸應(yīng)用中，盡量少的延遲正是我們所期望的。 由此可見(jiàn)，TCP協(xié)議是不適合用來(lái)傳輸實(shí)時(shí)視音頻數(shù)據(jù)的，為了實(shí)現(xiàn)視音頻數(shù)據(jù)的實(shí)時(shí)傳輸，我們需要尋求其它的途徑。2.RTP協(xié)議適合實(shí)時(shí)視音頻傳輸 RTP（Real-Time Transport Protocol）/RTCP（Real-Time Transport Control Protocol）是一種應(yīng)用型的傳輸層協(xié)議，它并不提供任何傳輸可靠性的保證和流量的擁塞控制機(jī)制。它是由IETF（Internet Engineering Task Force）為視音頻的實(shí)時(shí)傳輸而設(shè)計(jì)的傳輸協(xié)議。RTP協(xié)議位于UDP協(xié)議之上，在功能上獨(dú)立于下面的傳輸層（UDP）和網(wǎng)絡(luò)層，但不能單獨(dú)作為一個(gè)層次存在，通常是利用低層的UDP協(xié)議對(duì)實(shí)時(shí)視音頻數(shù)據(jù)進(jìn)行組播（Multicast）或單播（Unicast）,從而實(shí)現(xiàn)多點(diǎn)或單點(diǎn)視音頻數(shù)據(jù)的傳輸。 UDP是一種無(wú)連接的數(shù)據(jù)報(bào)投遞服務(wù)，雖然沒(méi)有TCP那么可靠，并且無(wú)法保證實(shí)時(shí)視音頻傳輸業(yè)務(wù)的服務(wù)質(zhì)量（QoS）,需要RTCP實(shí)時(shí)監(jiān)控?cái)?shù)據(jù)傳輸和服務(wù)質(zhì)量，但是，由于UDP的傳輸延時(shí)低于TCP，能與音頻和視頻流很好地匹配。因此，在實(shí)際應(yīng)用中，RTP/RTCP/UDP用于音視頻媒體，而TCP用于數(shù)據(jù)和控制信令的傳輸。 總結(jié)：如果接收端和發(fā)送端處于同一個(gè)局域網(wǎng)內(nèi)，由于有充分的帶寬保證，在滿(mǎn)足視頻傳輸?shù)膶?shí)時(shí)性方面，TCP也可以有比較好的表現(xiàn)，TCP和基于UDP的RTP的視頻傳輸性能相差不大。由于在局域網(wǎng)內(nèi)帶寬不是主要矛盾，此時(shí)視頻數(shù)據(jù)傳輸所表現(xiàn)出來(lái)的延時(shí)主要體現(xiàn)為處理延時(shí)，它是由處理機(jī)的處理能力以及采用的處理機(jī)制所決定的 。但是當(dāng)在廣域網(wǎng)中進(jìn)行視頻數(shù)據(jù)傳輸時(shí)，此時(shí)的傳輸性能極大地取決于可用的帶寬，由于TCP是面向連接的傳輸層協(xié)議，它的重傳機(jī)制和擁塞控制機(jī)制，將使網(wǎng)絡(luò)狀況進(jìn)一步惡化，從而帶來(lái)災(zāi)難性的延時(shí)。同時(shí)，在這種網(wǎng)絡(luò)環(huán)境下，通過(guò)TCP傳輸?shù)囊曨l數(shù)據(jù)，在接收端重建、回放時(shí)，斷點(diǎn)非常明顯，體現(xiàn)為明顯的斷斷續(xù)續(xù)，傳輸?shù)膶?shí)時(shí)性和傳輸質(zhì)量都無(wú)法保障。相對(duì)而言，采用RTP傳輸?shù)囊曨l數(shù)據(jù)的實(shí)時(shí)性和傳輸質(zhì)量就要好得多。四視頻圖像的異地顯示當(dāng)