scan8确实不好理解，解答如下：
static const int x264_scan8[16+2*4] =
{
/* Luma */
4+1*8, 5+1*8, 4+2*8, 5+2*8,
6+1*8, 7+1*8, 6+2*8, 7+2*8,
4+3*8, 5+3*8, 4+4*8, 5+4*8,
6+3*8, 7+3*8, 6+4*8, 7+4*8,
/* Cb */
1+1*8, 2+1*8,
1+2*8, 2+2*8,
/* Cr */
1+4*8, 2+4*8,
1+5*8, 2+5*8,
};
/*
0 1 2 3 4 5 6 7
0
1 B B L L L L
2 B B L L L L
3 L L L L
4 R R L L L L
5 R R
*/
上面这两个对应起来看就可以了。
scan8是为了便于访问 诸如mv_cache, ref_cache, non_zero_count_cache以及mvd_cache等内存，而填充好的一个数组，里面放置的都是上述内存中特定的索引序号
比如scan8[0]=12,这个12就是上述内存中，一般针对macroblock而言的左上角数值，无论是mv，还是non_zero_count，所以只有充分搞懂上述内存结构，那么所有问题就迎刃而解了 |
attachment中是以前针对某个问题，分析后的笔记
ffmepg中，几个比较重要的cache，大致都是按照此思路进行设置的
希望对于cache理解有帮助！
1.请问色度为什么和Luma度是同一矩阵值？
2.h->block_offset是求什么的值？
- for(i=0; i<16; i++){
- h->block_offset[i]= 4*((scan8[i] - scan8[0])&7) + 4*s->linesize*((scan8[i] - scan8[0])>>3);
- h->block_offset[24+i]= 4*((scan8[i] - scan8[0])&7) + 8*s->linesize*((scan8[i] - scan8[0])>>3);
- }
- for(i=0; i<4; i++){
- h->block_offset[16+i]=
- h->block_offset[20+i]= 4*((scan8[i] - scan8[0])&7) + 4*s->uvlinesize*((scan8[i] - scan8[0])>>3);
- h->block_offset[24+16+i]=
- h->block_offset[24+20+i]= 4*((scan8[i] - scan8[0])&7) + 8*s->uvlinesize*((scan8[i] - scan8[0])>>3);
- }
复制代码
1、应该是为了节约内存，同时方便在一个数组中索引同一个MB的亮色度的预测模式。不知这样解释是否正确，希望高人指正
2、block_offset，看名字就知道是block的偏移量啊 16+8，就更加明显啦，16个亮度，两个（8，各为4）色度
如果没记错的话，这个偏移应该是用在yuv像素存储索引的 |
|
感谢Juanny 的文档，对于理解x264_scan8中的元素值很有帮组，这主要是一个中间的寻址矩阵，通过它可以很方便的找到MB的色度、亮度4x4块在对应的cache,zero_count中的位置
scan8[]实际上是4x4块的扫描顺序及存储的位置，把scan8放在8x8的矩阵中就能看出其作用了，其中T表示当前块的上面的块，L表示当前块左边的块，它们是用来预测当前块的帧内预测模式(Intra prediction mode)和运动向量之类的，起到一个缓存的作用。可以看到这种设计比JM节约内存，而且非常巧妙。程序中的其他缓存设计都与此类似。
|
|
T
|
T
|
|
T
|
T
|
T
|
T
|
|
L
|
16
|
17
|
L
|
0
|
1
|
4
|
5
|
|
L
|
18
|
19
|
L
|
2
|
3
|
6
|
7
|
|
|
T
|
T
|
L
|
8
|
9
|
12
|
13
|
|
L
|
20
|
21
|
L
|
10
|
11
|
14
|
15
|
|
L
|
22
|
23
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
