攝像頭視頻採集壓縮及傳輸原理

攝像頭基本的功能仍是視頻傳輸，那麼它是依靠怎樣的原理來實現的呢？所謂視頻傳輸:
  就是將圖片一張張傳到屏幕，因爲傳輸速度很快，因此可讓你們看到連續動態的畫面，就像放電影同樣。通常當畫面的傳輸數量達到每秒24幀時，畫面就有了連續性。
下邊咱們將介紹攝像頭視頻採集壓縮及傳輸的整個過程。
一．攝像頭的工做原理（獲取視頻數據）
攝 像頭的工做原理大體爲：景物經過鏡頭（LENS）生成的光學圖像投射到圖像傳感器表面上，而後轉爲電信號，通過A/D（模數轉換）轉換後變爲數字圖像信 號，再送到數字信號處理芯片（DSP）中加工處理，再經過USB接口傳輸到電腦中處理，經過顯示器就能夠看到圖像了。下圖是攝像頭工做的流程圖：

 
注1：圖像傳感器（SENSOR）是一種半導體芯片，其表面包含有幾十萬到幾百萬的光電二極管。光電二極管受到光照射時，就會產生電荷。
注2：數字信號處理芯片DSP（DIGITAL SIGNAL PROCESSING）功能：主要是經過一系列複雜的數學算法運算，對數字圖像信號參數進行優化處理，並把處理後的信號經過USB等接口傳到PC等設備。
DSP結構框架:
1. ISP（image signal processor）（鏡像信號處理器）
2. JPEG encoder（JPEG圖像解碼器）
3. USB device controller（USB設備控制器）
而視頻要求將獲取的視頻圖像經過互聯網傳送到異地的電腦上顯示出來這其中就涉及到對於得到的視頻圖像的傳輸。
在 進行這種圖片的傳輸時，必須將圖片進行壓縮，通常壓縮方式有如H.26一、JPEG、MPEG等，不然傳輸所需的帶寬會變得很大。你們用 RealPlayer不知是否留意，當播放電影的時候，在播放器的下方會有一個傳輸速度250kbps、400kbps、1000kbps…畫面的質量越 高，這個速度也就越大。而攝像頭進行視頻傳輸也是這個原理，若是將攝像頭的分辨率調到640×480，捕捉到的圖片每張 大小約爲50kb左右，每秒30幀，那麼攝像頭傳輸視頻所需的速度爲50×30/s＝1500kbps＝1.5Mbps。而在實際生活中，人們通常用於網 絡視頻聊天時的分辨率爲320×240甚至更低，傳輸的幀數爲每秒24幀。換言之，此時視頻傳輸速率將不到300kbps，人們就能夠進行較爲流暢的視頻 傳輸聊天。若是採用更高的壓縮視頻方式，如MPEG-1等等，能夠將傳輸速率下降到200kbps不到。這個就是通常視頻聊天時，攝像頭所需的網絡傳輸速 度。
二．視頻壓縮部分
視頻的壓縮是視頻處理的核心，按照是否實時性能夠分爲非實時壓縮和實時壓縮。而視頻傳輸（如QQ視頻即時聊天）屬於要求視頻壓縮爲實時壓縮。
下面對於視頻爲何能壓縮進行說明。
視頻壓縮是有損壓縮，通常說來，視頻壓縮的壓縮率都很高，可以作到這麼
高 的壓縮率是由於視頻圖像有着很是大的時間和空間的冗餘度。所謂的時間冗餘度指的是兩幀相鄰的圖像他們相同位置的像素值比較相似，具備很大的相關性，尤爲是 靜止圖像，甚至兩幀圖像徹底相同，對運動圖像，經過某種運算（運動估計），應該說他們也具備很高的相關性；而空間相關性指的是同一幀圖像，相鄰的兩個像素 也具有必定的相關性。這些相關性是視頻壓縮算法的初始假設，換句話說，若是不知足這兩個條件（全白噪聲圖像，場景頻繁切換圖像等），視頻壓縮的效果是會很 差的。
去除時間相關性的關鍵算法是運動估計，它找出當前圖像宏塊在上一幀圖像中最匹配的位置，不少時候，咱們只須要把這個相對座標記錄下來，就夠 了，這樣就節省了大量碼字，提升了壓縮率。視頻壓縮算法中，運動估計永遠是最關鍵最核心的部分。去除空間相關性是經過DCT變換來實現的，把時域上的數據 映射到頻域上，而後對DCT係數進行量化處理，基本上，全部的有損壓縮，都會有量化，它提升壓縮率最明顯。
圖像的原始文件是比較大的，必須通過圖 像壓縮纔可以進行快速的傳輸以及順暢的播放。而壓縮比正是來衡量影像壓縮大小的參數。通常來講，攝像頭的壓縮比率大都是5:1。也就是說，若是在未壓縮之 前30秒的圖像的容量是30MB，那麼按照攝像頭5:1的壓縮比率來對圖像進行壓縮之後，它的大小就變成了6MB了。
主要的視頻壓縮算法包括：M-JPEG、Mpeg、H.26四、Wavelet（小波壓縮）、JPEG 2000、AVS。
基本上視頻壓縮的核心就這些。
三．視頻傳輸部分
爲了保證數字視頻網絡傳輸的實時性和圖像的質量，傳輸層協議的選擇是整個設計和實現的關鍵。Internet在IP層上使用兩種傳輸協議：一種是TCP(傳輸控制協議)，它是面向鏈接的網絡協議；另外一種是UDP(用戶數據報協議)，它是無鏈接的網絡協議。
TCP傳輸：TCP（傳輸控制協議）是一種面向鏈接的網絡傳輸協議。支持多數據流操做，提供流控和錯誤控制，乃至對亂序到達報文的從新排序，所以，TCP傳輸提供了可靠的數據傳輸服務。
使用TCP傳輸的通常的過程：
客戶機向服務器發出鏈接的請求後，服務器接收到後，向客戶機發出鏈接確認，實現鏈接後，雙方進行數據傳輸。
UDP 傳輸： UDP（用戶數據報協議）是一種無鏈接的網絡傳輸協議。提供一種基本的低延時的稱謂數據報的傳輸服務。不須要像TCP傳輸同樣需預先創建一條鏈接。UDP 無計時機制、流控或擁塞管理機制。丟失的數據不會重傳。所以提供一種不可靠的的應用數據傳輸服務。但在一個良好的網絡環境下如 局域網內，使用UDP傳輸數據仍是比較可靠，且效率很高。
IP組播技術：組播技術是一種容許一個或多個發送者發送單一或多個發送者的數據包到多個 接收者的網絡技術。組播源把數據報發送到特定的組播組，而只有加入到該組播組的主機才能接收到這些數據包。組播可大大節省網絡寬帶，由於不管有多少個目標 地址，在整個網絡的任何一條鏈路上只船送單一的數據包。
1.TCP/IP協議和實時傳輸
TCP/IP協議最初是爲提供非實時數據業務而設 計的。IP協議負責主機之間的數據傳輸，不進行檢錯和糾錯。所以，常常發生數據丟失或失序現象。爲保證數據的可靠傳輸，人們將TCP協議用於IP數據的傳 輸，以提升接收端的檢錯和糾錯能力。當檢測到數據包丟失或錯誤時，就會要求發送端從新發送，這樣一來就不可避免地引發了傳輸延時和耗用網絡的帶寬。所以傳 統的TCP/IP協議傳輸實時音頻、視頻數據的能力較差。固然在傳輸用於回放的視頻和音頻數據時，TCP協議也是一種選擇。若是有足夠大的緩衝區、充足的 網絡帶寬，在TCP協議上，接近實時的視音頻傳輸也是可能的。然而，若是在丟包率較高、網絡情況很差的狀況下，利用TCP協議進行視頻或音頻通訊幾乎是不 可能的。
  TCP和其它可靠的傳輸層協議如XTP不適合實時視音頻傳輸的緣由主要有如下幾個方面：
  1 .TCP的重傳機制
  咱們知道，在TCP/IP協議中，當發送方發現數據丟失時，它將要求重傳丟失的數據包。然而這將須要一個甚至更多的週期（根據TCP/IP的快速重傳機 制，這將須要三個額外的幀延遲），這種重傳對於實時性要求較高的視音頻數據通訊來講幾乎是災難性的，由於接收方不得不等待重傳數據的到來，從而形成了延遲 和斷點（音頻的不連續或視頻的凝固等等）。
  2 .TCP的擁塞控制機制
  TCP的擁塞控制機制在探測到有數據包丟失時，它就會減少它的擁塞窗口。而另外一方面，音頻、視頻在特定的編碼方式下，產生的編碼數量（即碼率）是不可能忽然改變的。正確的擁塞控制應該是變換音頻、視頻信息的編碼方式，調節視頻信息的幀頻或圖像幅面的大小等等。
  3 .TCP報文頭的大小
  TCP不適合於實時視音頻傳輸的另外一個缺陷是，它的報文頭比UDP的報文頭大。TCP的報文頭爲40個字節，而UDP的報文頭僅爲12個字節。而且，這些 可靠的傳輸層協議不能提供時間戳（Time Stamp）和編解碼信息（Encoding Information），而這些信息偏偏是接收方（即客戶端）的應用程序所須要的。所以TCP是不適合於視音頻信息的實時傳輸的。
  4 .啓動速度慢
  即使是在網絡運行狀態良好、沒有丟包的狀況下，因爲TCP的啓動須要創建鏈接，於是在初始化的過程當中，須要較長的時間，而在一個實時視音頻傳輸應用中，儘可能少的延遲正是咱們所指望的。
  因而可知，TCP協議是不適合用來傳輸實時視音頻數據的，爲了實現視音頻數據的實時傳輸，咱們須要尋求其它的途徑。
2.RTP協議適合實時視音頻傳輸
  RTP（Real-Time Transport Protocol）/RTCP（Real-Time Transport Control Protocol）是一種應用型的傳輸層協議，它並不提供任何傳輸可靠性的保證和流量的擁塞控制機制。它是由IETF（Internet Engineering Task Force）爲視音頻的實時傳輸而設計的傳輸協議。RTP協議位於UDP協議之上，在功能上獨立於下面的傳輸層（UDP）和網絡層，但不能單獨做爲一個層 次存在，一般是利用低層的UDP協議對實時視音頻數據進行組播（Multicast）或單播（Unicast）,從而實現多點或單點視音頻數據的傳輸。
  UDP是一種無鏈接的數據報投遞服務，雖然沒有TCP那麼可靠，而且沒法保證明時視音頻傳輸業務的服務質量（QoS）,須要RTCP實時監控數據傳輸和服 務質量，可是，因爲UDP的傳輸延時低於TCP，能與音頻和視頻流很好地匹配。所以，在實際應用中，RTP/RTCP/UDP用於音視頻媒體，而TCP用 於數據和控制信令的傳輸。 
總結：若是接收端和發送端處於同一個局域網內，因爲有充分的帶寬保證，在知足視頻傳輸的實時性方面，TCP也能夠有 比較好的表現，TCP和基於UDP的RTP的視頻傳輸性能相差不大。因爲在局域網內帶寬不是主要矛盾，此時視頻數據傳輸所表現出來的延時主要體現爲處理延 時，它是由處理機的處理能力以及採用的處理機制所決定的 。可是當在廣域網中進行視頻數據傳輸時，此時的傳輸性能極大地取決於可用的帶寬，因爲TCP是面向鏈接的傳輸層協議，它的重傳機制和擁塞控制機制，將使網 絡情況進一步惡化，從而帶來災難性的延時。同時，在這種網絡環境下，經過TCP傳輸的視頻數據，在接收端重建、回放時，斷點很是明顯，體現爲明顯的斷斷續 續，傳輸的實時性和傳輸質量都沒法保障。相對而言，採用RTP傳輸的視頻數據的實時性和傳輸質量就要好得多。
四．視頻圖像的異地顯示
當壓 縮過的視頻經過互聯網傳輸到異地的時候，對於互聯網傳輸過來的視頻信息，首先是要進行解碼，而後纔是顯示。解碼的芯片有必定的性能要求，比編碼器低些，但 是畢竟是視頻數據處理，通用的芯片（不支持MMX等多媒體指令）可能會比較吃力。顯示設備主要有電視、監視器和顯示器，他們的信號接口是不同的，電視監 視器是模擬的電信號，顯示器的輸入應該是數字信號。
以上是攝像頭如何獲取圖像數據及獲取的數據存放在什麼地方，如何壓縮和傳輸及如何在異地釋放和播放出來的整個過程