Let's start with this pair of arrays since it's shorter:
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 feeds these into this function in ituh263dec.c:
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 uses these pairs of bits/codes arrays to set up variable length codes (VLCs), a.k.a. Huffman codes. In this case, the function will initialize a data structure named ff_h263_intra_MCBPC_vlc
. The fact that there are 9 items in each array means that there are 9 possible values (0..8). the first item is code 1 and 1 bit long. The second item is also code 1 but has a length of 3. That means, in binary, it is 001. Let's expand this out:
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
The decoder will be able to leverage the ff_h263_intra_MCBPC_vlc
data structure by feeding the bitstream into it and getting a value back out, ranging from (0..8), then consuming somewhere between (1..9) bits from the stream.
As for your question: What does "Stuffing" mean?, note that in both the codes and bits arrays, there are entries that are 0-- i.e., the code is 0 and it's 0 bits long. Those are invalid values. Since these arrays have 28 values ranging from (0..27). This means that 21, 22, and 23 can't be represented.
I hope I've answered your questions about the mechanics of how FFmpeg handles these arrays (and I hope that was the main substance of your query).
Pretty Picture Time:
Huffman/VLC codes are usually illustrated using trees. Starting from the top, a 0 travels to the left and a 1 travels to the right. When you get reach a leaf node, you have decoded a value.