嵌入式視頻處理基礎(三)

時間 2019-11-21

標籤嵌入視頻處理基礎简体版

原文原文鏈接

引言：算法

做爲消費者，咱們對於各類形式的視頻系統都已經很是熟悉了。可是從嵌入式開發人員的角度來看，視頻就好像是一張紛繁複雜的網絡，裏面充滿了各類不一樣的分辨率、格式、標準與顯示等。微信

數字視頻：網絡

在20世紀90年代中期以前，幾乎全部的視頻都是模擬類型的。直到出現了MPEG-2壓縮標準，流媒體在互聯網上普遍流行，以及FCC(Federal Communications Commission,美國聯邦電信委員會)採用了數字電視(DTV)標準，才產生了一次所謂的」完美風暴」，也就是把數字表示方法的好處帶到了視頻領域內。相對模擬視頻而言，數字視頻的優勢包括:更高的信噪比，提升了帶寬利用率(在現有的每個模擬傳輸通道中可同時傳輸多個通道的數字視頻信號)，以及經過數字壓縮技術下降了對存儲空間的要求。編碼

從根本上來講，對模擬視頻信號進行數字化處理包括兩個方面:採樣和量化。在視頻幀的二維結構中，採樣就必須向畫格子同樣，先將圖像按空間劃分爲一些小的區域，而後根據每一個區域顏色空間成分強度的不一樣分配一些相對的幅值。須要注意的是，模擬視頻已經通過了垂直採樣(離散的行數)和時間採樣(每秒離散的幀數)。spa

採樣與量化3d

量化是這樣一個過程:在採樣過程當中決定那些離散的幅度值。在消費領域內，常常用8比特的視頻，也就是說在每一個顏色通道(RGB或者YCbCr)中用0表示最暗(即純黑色)，用255表示最亮(即白色)。可是，咱們應該注意到，每一個顏色一般中10比特和12比特的量化正在快速進入主流的視頻品中，這些額外的精度能夠用來減少舍入偏差，從而下降接受圖像的噪聲。視頻

經常使用視頻採樣率blog

數字視頻的出現，在很大程度上爲NTSC和PAL系統接口的標準化提供了一個極好的機會。當國際電信聯盟(ITU)開會制定數字視頻標準的建議時，主要議題集中在如何實現NTSC和PAL標準之間最大程度的共用性，這樣一來，兩個標準就能夠共享同一種編碼格式。接口

國際電信聯盟(ITU)定義了兩個各自獨立的建議——ITU-R BT.601和ITU-R BT.656。這兩個建議放在一塊兒，就定義了一種結構，可使不一樣的數字視頻系統進行互操做。BT.601定義了數字視頻傳輸的參數，而BT.656定義了接口自己。ci

FPGA處理656格式視頻數據流

ITU-RBT.601：

BT.601標註定義了以數字方式編碼視頻信號的方法，爲了有效利用通道的帶寬，使用了YcbCr顏色空間。該標註中建議將4:2:2 YcbCr做爲廣播視頻中優先的格式。另外還提供了同步信號(HSYNC’ VSYNC’FIELD)和一個時鐘信號，用來描述活動視頻區域的邊界。

每個BT.601像素份量(Y’Cr或Cb)被量化爲8比特或10 比特，NTSC和PAL系統的活動視頻區域中每一行有720像素。可是，這兩個系統在垂直分辨率上有所不一樣。30幀/秒的NTSC系統有525行(包括垂直消隱或者回掃區)，而25幀/秒的PAL系統比NTSC系統增長了100行，達到625行，這樣PAL系統也適用一樣的標準。

ITU-RBT.601輸入時序圖

BT.601標準中規定，Y份量在名義上的數值範圍是16(純黑)到235(全白)。色度份量Cb和Cr的數值範圍是16~240，數值128至關於沒有顏色。有時候，因爲噪聲或者舍入偏差的影響，有的值落在了名義範圍以外，可是卻永遠不會超過0~255的範圍。

ITU-R BT.656：

BT.601描述的是如何對視頻信號進行數字化編碼，而BT.601所必須的物理接口和數據流。該標準定義了並行和串行兩種模式。並行模式僅僅須要一個27MHz的時鐘信號(NTSC 30幀/秒)和8或者10根數據線(根據像素的分辨率調整)。全部的同步信號都內嵌在數據流中，於是不須要額外的硬件連線。下圖是使用嵌入式幀同步信號時的經常使用時序關係，包括BT:656 4:2:2YcbCr格式，以及」BT.656風格」的4:4:4YcbCr和RGB格式。

經常使用數字視頻格式

串行模式下，只須要在單個通道上有一個多路複用的每像素10比特的串行數據流，可是這中間涉及一些複雜的技術，例如同步，頻譜定形和時鐘恢復等。並且，碼流時鐘頻率接近300MHz，因此在許多系統中，實現串行BT.656是一個挑戰。

ITU-R BT.656幀分割

ITU-R BT.656數據流

在BT.656標準中，水平同步(H)、垂直同步(V)和場同步(F)信號做爲食品數據流中的一部分發送，這些數據構成了一個控制字。活動視頻起始(SAV)信號和活動視頻結束(EAV)信號表示每一行須要讀入的數據的開始點和結束點。SAV是指H信號由1變爲0，EAV是指H信號由0變爲1。視頻的一個整場由活動視頻、水平消隱(EAV和SAV碼子之間的間隔)和垂直消隱(V=1的間隔)組成。

一個視頻的場從F比特的變化開始。」奇數場」由F=0表示，而F=1則表示」偶數場」。逐行掃描的視頻中，場1和場2 之間沒有任何區別，可是在隔行掃描視頻中，則要求專門對每個場進行獨立的處理，由於每一個場中交替的掃描行組合起來構成了實際的視頻圖像幀。

SAV/EAV前導信息碼

上圖列出了關於SAV和EAV碼字的具體細節。要注意的是，在前面由一個預約義的長度爲3個字節的前導信息(對於8比特視頻爲0xFF、0x00、0x00,對於10 比特視頻爲0x3FF、0x000、0x000)，後面緊跟着的是控制字節，依次爲F(場)、V(處置消隱)和H(水平消隱)位，而後爲4個保留位吧，用於單比特的錯誤檢測和糾正。注意，F和V僅僅容許在EAV序列(也就是說H從0變爲1)中改變。另外還要注意，對於10比特的視頻，額外的兩個比特加在了最低有效位，而不是加在最高有效位。

各個比特的定義以下：

- F=0表示場1
- F=1表示場2
- V=1表示垂直消隱區
- V=0表示不在垂直消隱區
- H=0表示SAV
- H=1表示EAV
- P3=V XOR H
- P2=F XOR H
- P1=F XOR V
- P0=F XOR V XORH

垂直消隱的間隔內(即V=1的時間段)，能夠用來發送一些非視頻的信息，例如音頻、圖文電視、閉路字幕，甚至是互動電視應用中的數據。BT.656使用輔助數據包實現了這種功能。和正常的控制字節前面的前導信息」0xFF、0x00、0x00」不一樣的是，輔助數據包的前導信息爲」0x00、0xFF、0xFF」。

假定不發送輔助數據，水平消隱和垂直消隱期間，(Cb、Y、Cr、Y、Cb、Y、···)數據流是(0x80、0x十、0x80、0x十、0x80、0x十、···)。另外，因爲數值0x00和0xFF專門留做控制前導字之用，它們不容許做爲活動視頻流中的一部分。在10 比特的系統中，數值0x00到0x003和0x3FC到0x3FF頁保留值，以避免引發8比特實現時一樣的問題。

從系統角度看視頻：

上圖是一個常見的端到端嵌入式數字視頻系統。在這種狀況下，視頻源輸入到媒體處理器中(若是必要的話，首先要有視頻解碼器進行數字化處理)。視頻數據在存儲到本地或者發送到網絡以前還須要用軟件編碼器進行壓縮處理。

與此過程相反，咱們能夠從網絡或者大容量存儲器中獲得壓縮碼流。而後經過軟件解碼器解壓縮後，直接發送到數字輸出顯示設備上(例如TFT-LCD屏)進行顯示，或者經過視頻編碼器轉化爲模擬信號，從而能夠在傳統的CRT顯示器上進行顯示。

視頻壓縮編碼標準發展趨勢

請緊緊記住，壓縮和解壓縮僅僅是媒體處理器上可實現的全部可能視頻處理算法中的一部分而已。

因爲篇幅，嵌入式視頻基礎這期內容先分享到這裏，下期更精彩。

版權全部權歸卿萃科技，轉載請註明出處

做者：卿萃科技ALIFPGA

原文地址：卿萃科技FPGA極客空間微信公衆號

掃描二維碼關注卿萃科技FPGA極客空間