這兩部分libavcodec/h263data.h究竟做了什麼？

下面是來自FFMPEG庫的兩段代碼，具體位於這裏：libavcodec/h263data.h（http://ffmpeg.org/doxygen/0.6/h263data_8h-source.html）。這兩部分libavcodec/h263data.h究竟做了什麼？

我想知道更多關於這兩個段如何在編解碼器庫的更大範圍內運行。下面，通過這些例子，我描述了迄今爲止的理解，並提供了兩個我希望得到答案的更清晰的問題。

謝謝任何幫助！

例1

00035 /* intra MCBPC, mb_type = (intra), then (intraq) */ 
00036 const uint8_t ff_h263_intra_MCBPC_code[9] = { 1, 1, 2, 3, 1, 1, 2, 3, 1 }; 
00037 const uint8_t ff_h263_intra_MCBPC_bits[9] = { 1, 3, 3, 3, 4, 6, 6, 6, 9 };

和示例2

00039 /* inter MCBPC, mb_type = (inter), (intra), (interq), (intraq), (inter4v) */ 
00040 /* Changed the tables for interq and inter4v+q, following the standard ** Juanjo ** */ 
00041 const uint8_t ff_h263_inter_MCBPC_code[28] = { 
00042  1, 3, 2, 5, 
00043  3, 4, 3, 3, 
00044  3, 7, 6, 5, 
00045  4, 4, 3, 2, 
00046  2, 5, 4, 5, 
00047  1, 0, 0, 0, /* Stuffing */ 
00048  2, 12, 14, 15, 
00049 };

據我所知，我們正在尋找影響正交方案的壓縮算法的大庫的一小部分，其預測「正確的」或更恰當地放置「原始」的運動間或運動內矢量，其在名稱「ff_h263」 _inter_MCBPC_code「，」ff_h263_intra_MCBPC_code「和」ff_h263_intra_MCBPC_bits「。

我知道，在這些代碼兩個街區的名字劃分如下：

常量指的閱讀聲明唯一的變量可還在外面等中使用的範圍任何其他變量。另一種說法是，這個數組中的值不能被任何外部調用的方法改變。
uint8_t是無符號整數具有8個比特的長度是一個C99的標準，這就是所謂的部分「固定寬度整數類型」。這種特定類型，即「精確寬度整數」，計算最小值爲0且最大值爲8的帶符號或無符號位的範圍（即8x8宏塊），這保證跨平臺的這個位數，比方說，32位或64位操作系統。（我研究這個位在這裏：「固定寬度整數類型」 http://en.wikipedia.org/wiki/Stdint.h#stdint.h）
MCBPC指宏塊類型&色度塊編碼模式，但我並不完全瞭解這些特定陣列的確切作用是該文件的方案和libavcodec。我從概念上理解更多，比我在這些例子中定義的細節/數字值更重要。

因此，考慮這一點，這是我想多瞭解一下：

我的理解是，迄今爲止，關以任何方式？
有人可以幫助分解每個代碼段做什麼？ 更具體地說，這些數值在每種情況下表示/做什麼？
「餡」是什麼意思？

再次感謝您對此事的任何幫助！

來源

2013-04-02 Chris Lindgren

我從來沒有真正看的H.263編解碼器，但我認爲，關鍵是尋找那些標識符（'ff_h263_intra_MCBPC_code'等）在源代碼中的其他地方怎麼看/他們在哪裏實際使用......從他們的定義來確定是相當困難的... – twalberg

讓我們開始與這對陣列的，因爲它是更短的：

INIT_VLC_STATIC(&ff_h263_intra_MCBPC_vlc, INTRA_MCBPC_VLC_BITS, 9, 
     ff_h263_intra_MCBPC_bits, 1, 1, 
     ff_h263_intra_MCBPC_code, 1, 1, 72);

FFmpeg的使用這些對位/碼陣列的給：

const uint8_t ff_h263_intra_MCBPC_code[9] = { 1, 1, 2, 3, 1, 1, 2, 3, 1 }; 
const uint8_t ff_h263_intra_MCBPC_bits[9] = { 1, 3, 3, 3, 4, 6, 6, 6, 9 };

FFmpeg的在ituh263dec.c饋送這些到該功能設置可變長度碼（VLC），又名霍夫曼碼。在這種情況下，該函數將初始化一個名爲ff_h263_intra_MCBPC_vlc的數據結構。每個數組中有9個項目的事實意味着有9個可能的值（0..8）。第一項是代碼1和1位長。第二項是也代碼1，但具有3的長度這意味着，在二進制的，它是001。讓我們這擴大了：

value code bitcount bits 
    0  1  1  1 
    1  1  3  001 
    2  2  3  010 
    3  3  3  011 
    4  1  4  0001 
    5  1  6  000001 
    6  2  6  000010 
    7  3  6  000011 
    8  1  9  000000001

解碼器將能夠通過餵食以利用ff_h263_intra_MCBPC_vlc數據結構比特流輸入並取回一個值，範圍從（0..8），然後消耗在流的（1..9）比特之間。

至於你的問題：「餡」是什麼意思？，注意，在代碼和位數組中，都有條目是0--即代碼是0並且它是0位長。那些是無效的價值。由於這些數組有28個值，範圍從（0..27）。這意味着21,22和23不能代表。

我希望我已經回答了關於FFmpeg如何處理這些數組的機制問題（我希望這是您查詢的主要內容）。

漂亮的圖片時間：

使用樹霍夫曼/ VLC代碼通常所示。從頂部開始，0向左移動，1向右移動。當你到達葉節點時，你已經解碼了一個值。

H.263 intraframe macroblock coded block pattern for chroma VLC table

來源

2013-04-05 05:32:23

謝謝！這當然有助於我1）更好地看待這個過程，2）爲我提供一些研究下一個過程的方法。 –

這兩部分libavcodec/h263data.h究竟做了什麼？

回答

相關問題