这两部分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究竟做了什么？

回答

相关问题