引言：

作為消費者，我們對於各種形式的視頻系統都已經非常熟悉了。但是從嵌入式開發人員的角度來看，視頻就好像是一張紛繁復雜的網絡，裏面充滿了各種不同的分辨率、格式、標準與顯示等。

數字視頻：

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

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

采樣與量化

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

常用視頻采樣率

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

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

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、0x10、0x80、0x10、0x80、0x10、···)。另外，由於數值0x00和0xFF專門留作控制前導字之用，它們不允許作為活動視頻流中的一部分。在10 比特的系統中，數值0x00到0x003和0x3FC到0x3FF頁保留值，以免引起8比特實現時同樣的問題。

從系統角度看視頻：

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

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

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

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

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

版權所有權歸卿萃科技，轉載請註明出處

作者：卿萃科技ALIFPGA

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

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

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