H.263視頻編碼

應用程序視頻會議和視頻電信有很廣泛的程序應用，包括：桌面環境或室內環境下的會議系統通過Internet或電話線路實現的視頻通信電子監視和操作運程醫療（在運程進行醫學諮詢和診斷）基於計算機的培訓與教育在每種應用中，視頻信息（也許與音頻信息一塊兒）被通過電信通訊聯接傳輸，包括網絡，電話線路，ISDN和廣播的形式。視頻有寬頻的特徵（比如説每秒很多字節）這些，這些應用就需要對視頻進行壓縮或是進行編碼來在傳輸之前降低帶寬值。

在源端視頻信息幀被捕捉並被通過視頻編碼器進行編碼。壓縮的注被通過網絡或是電信聯接傳輸走，並在視頻解碼端進行解碼。解碼過的幀就可以被顯示了。

H.263編碼器運動估計和補償降低帶寬的第一步就是從當前幀中減去之前傳輸的幀，這樣只有差值或叫殘差值才被編碼並傳輸。這就意味着幀中沒有變化的內容就不被 編碼。我們通過試圖對於當前幀的內容的移動進行估計並補償這個運動值來實現更高的壓縮比。運動估計模塊通過在當前幀中和在前些幀中周圍的區域比較每個16*16的像素塊(宏塊)，並試圖找到一個匹配的幀。匹配的區域從當前的宏塊位置中由運動補償模塊刪除掉。如果運動估計和補償過程很有效率的話，剩餘的宏塊應該只包含很少量的信息。

離散餘弦變換(DCT) DCT把一塊像素值(或剩餘幀值)變換到一系列“頻域“係數中。這就好像利用快速傅里葉變換(FFT)把一個信號從時域轉變到頻域中一樣的。 DCT在一個二維的像素塊上(而不是一個一維的信號)進行操作，它尤其長於把塊中的能量壓縮到一系列的係數中去。這就意味着，通過很少量的DCT係數，我們就可以重建一個原始像素塊的拷貝。

量化對於一個典型的像素塊來説，用DCT得到的大多數的係數都是接近於0的。量化器模塊降低了每個係數的準確性，這樣近似於0的值就被置 0，而且只有一些非0值留下來了。實際操作中，我們通過整數級因子來劃分係數值，並截去結果。很重要的一點是我們在量化過程中“扔掉”了一些信息。

熵編碼 一個熵編碼器（比如説Huffman編碼器）把常出現的值用更短的二進制碼來表示，並且把不常出現的值用長一些的二進制碼進行表示。 H.263中的熵編碼是基於這個技術的，並被用來壓縮量化後的DCT係數的。這個結果是一個序列的變長二進制。這些碼組合起來用來同步和控制信息（比如重建運動補償的參考幀時需要的運動向量），用以進成編碼的H.263碼流。幀存儲當前幀必須被存儲掉，這樣，它才可以在下一幀編碼的時候被用做參考幀。我們不是簡單地把當前存存儲起來，而是把逆量化的量化因子，用逆DCT操作後的反變換以及用來重建一幀的加到運動補償的參考塊信息存放在存儲區中。這就確保了在編碼器端幀存儲區中的內容與在解碼器的存儲區中的內容是相同的。當下一幀被編碼的時候，運動估計使用幀存儲區中的內容來決定運動補償的最佳匹配區域。

H.263解碼器熵解碼為了解壓出係數值和運動向量信息，組成H.263碼流的變長的編碼被進行解碼 重調節這是量化過程的反過程：係數被乘以一個在編碼端量化器同樣的標量因子。然而，因為量化器丟棄了小的因子，重調節之後的係數值不再同原始的係數值相等。 逆DCT IDCT是DCT過程的反變換。它構建了一塊採樣值：它們對應於編碼器端運動補償生成的差值。 運動補償 差值被加到前一幀來重建區域信息。運動向量信息用來選擇正確的區域（在編碼器中使用相同的參考幀）。結果是一個原始幀的重建：注意它將與原始幀不同，因為量化過程是有損的。也就是説圖像的質量會比原始幀差一些。重建的幀被放於一個幀存儲區，而且它被用於對下一個接收到的幀進行運動補償。

實時的視頻通信在實時情形下開發一個可以有效工作的視頻編碼和編碼器時,有很多問題是要被説明的,包括: 碼率控制 實際的通信信道對於每秒鐘它們可以處理的能力有限度.在很多種情形下,碼率是一個定值(比如説POTS,IDSN等) H.263編碼器的基礎是對於每個編碼的幀生成一個變的碼值.如果運動估計/補償過程工作正常的話,那麼就有更少的非0係數被用來編碼. 然而,如果運動估計工作不那麼正常的話(比如説當視頻場景中包括複雜的運動時),就會有很多的非0係數來被編碼.這樣編碼的值會增加. 為了映射這個可變的碼率值到一個CBR(固定碼率值)信道,編碼器必須進行碼率控制.編碼器計算編碼器輸出的碼率.如果它太高的話,它會通過增加標量化因子來提高壓縮率:這會導致更高的壓縮比(碼率會更低),但也同時在解碼器給出了更低的畫質.如果碼率下降的話,編碼 器就通過降低量化器的標量化因子來進行壓縮.這樣會在解碼端造成更高的友率和更佳的畫質. 同步 編碼器和解碼器必須是同步的,特別是如果視頻信號與音頻信號一起的話.H.263碼流包含了一定數目的"頭"或叫標記:這些是特殊的記號用來標記解碼器在當前幀的所處的位置.如果解碼器失掉了同步,那麼它就向前掃描下一個標記來重新同步並恢復解碼.應該注意到甚至是很小的同步上的損失都會造成很嚴重的解碼質量的問題.所以在這樣一個充滿了"嗓音"的傳輸環境中設計一個視頻編碼系統的時候必須非常小心. 音頻和複用 H.263標準只描述了視頻編碼.在很多實際問題中,音頻數據必須被壓縮,傳輸和同步到視頻信號中去.同步,複用和協議問題被像H.320 (基於ISDN的視頻會議),H.324(基於POTS的視頻電信)和H.323(LAN或基於IP的視頻會議)這樣的標準解決掉了.H.263提供了這些標準的視頻編碼方法.音頻編碼被很多標準所支持,包括G.723.1等.另外,相關的標準包含了像複用(H.223)和信號機制(H.245)

像運動估計，變長編/解碼和DCT這樣的函數需要很大的處理能力來實現。然而，最近的處理器的發展，使得在Pentium級處理器實時地編解 H.263視頻變成可能。 一個軟件實現必須是高度優化的，來達到有效的視頻質量（比如説，每秒多於10幀，352*288像素每幀）。這包括了一系列的操作比如説在計算密集處使用快速算法，最小化移動或拷貝操作並循環展開。在一些情況下，彙編代碼會進一步加速運行（比如説使用Inter的MMX指令集）

像運動估計，變長編/解碼和DCT這樣的函數需要很大的處理能力來實現。然而，最近的處理器的發展，使得在Pentium級處理器實時地編解 H.263視頻變成可能。 一個軟件實現必須是高度優化的，來達到有效的視頻質量（比如説，每秒多於10幀，352*288像素每幀）。這包括了一系列的操作比如説在計算密集處使對於高清晰的視頻來説或當強大的處理器不存在的時候，硬件實現就是這個時候的解決方案了。一個典型的CODEC會對計算密集的部分使用專門的硬件邏輯來進行處理（比如説運動估計/補償，DCT,量化器和熵編碼），它們使用控制模塊來定製事件順序，並記錄編碼解碼的參數。一個可編程的控制器是更佳的，因為很多的編碼參數（比如説碼率控制算法）可以通過適應不同的環境來進行修改或是調整。最近，一個 Intellectual Property中心對H.263提出了一個實現。一個邏輯核心是VHDL或者Verilog的設計，它可以與其他的功能模塊組合而成為一個 ASIC或FPGA的一部分。