那天摄像时背景是雪白的墙,结果解码时问题出现了。
问题现象:
解码的图像在墙壁部分有很明显的方块,其它图像变化大的地方(如人脸部分)情况还好。
问题分析:
以前没有这种情况的呀。改变了的只有编码速率。原来为了兼顾网络状况,我们将码率降得比较低。码率小,量化的精度就低,宏块与宏块之间的量化误差变大。当 颜色变化很平缓时,这种很小的误差就变得明显了,图像上的体现就是宏块边界出现明显的颜色跳变,也就是方块。
问题解决:
还好mpeg4标准考虑到了这个现象,他们提供了一种叫deblock的解码后处理方法来弱化这种现象。实际将deblock添加后图像确实平滑许多,方块也没了。
deblock原理:
大概做法就是将每个点与它上下10个点和左右10个点的颜色平均。具体做法是将图像按8*8划分成块,按块的边界做平均。 如下图所示。
| |
| |
块1 | 块2 | v0
v0 v1 v2 v3 v4|v5 v6 v7 v8 v9 | v1
| | v2
| | v3
| | v4
----------------------------------------------------------------
| | v5
| | v6
| | v7
块3 | 块4 | v8
| | v9
| |
| |
-----------------------------------------------------------------
每次计算取10个点,首先判断10个点的差别,如果差别很小就用默认模式将v4 v5做个细小的修正,如果差别很大则用DC offset模式修正v1-v8共8个点的值。判别的算法是:
eq_cnt = y(v0-v1) + y(v1-v2) + y(v2-v3) + y(v4-v5) + y(v5-v6)
+ y(v6-v7) + y(v7-v8)
其中if(x<= THR1) y(x) =0 else y(x) = 1; //THR1 是一个经验值 1
if(eq_cnt < THR2) //THR1 是一个经验值 6
default mode
else
DC offset mode
DC offset模式的规则:
max = MAX(v[1],v[2],v[3],v[4],v[5],v[6],v[7],v[8]);
min = MIN(v[1],v[2],v[3],v[4],v[5],v[6],v[7],v[8]);
if((max - min) < 2* quant)
颜色平均
else
什么也不做
按 1,1,2,2,4,2,2,1,1 的权重平均颜色。比如
s[1] = (uint8_t)((6*p0 +(v[1]<<2)+(v[2]<<1)+(v[3]<<1)+v[4]+v[5]+8)>>4);
s[2] = (uint8_t)(((p0<<2)+(v[1]<<1)+(v[2]<<2)+(v[3]<<1)+(v[4]<<1)+v[5]+v[6]+8)>>4);
s[3] = (uint8_t)(((p0<<1)+(v[1]<<1)+(v[2]<<1)+(v[3]<<2)+(v[4]<<1)+(v[5]<<1)+v[6]+v[7]+8)>>4);
类似的计算出s[1]-s[8],然后回写到v[1]-v[8]的位置。
计算量分析:
统计可以知道绝大部分使用了DC offset模式。如果图像尺寸是352*288,只分析亮度分量的计算量。
8*8块竖向分界线有352/8-1 = 43 条 ,每条分界线上有288个点,也就是竖向deblock要做43*288=12384个平均操作。
横向向分界线有288/8-1 = 35 条 ,每条分界线上有352个点,也就是竖向deblock要做35*352=12320个平均操作。
每个平均操作需要执行:
(1)从内存中读取10个byte, 竖向时10个byte是连续的,横向时每个byte相隔一行的宽度
(2)计算eq_cnt
(3)从v[1]-v[8]中找出最大的最小的值
(4)计算s[1]-s[8]
(5)将s[1]-s[8]存到v[1]-v[8]
另外,由于这些操作会修改图像的值,而如果图像是I或P帧,它还要作为后继帧的参考帧,图像数据不能变,所以需要将它拷贝到临时区中处理,这个拷贝也极耗时间。
天啦,每帧deblock将会大约读两遍帧数据和写一遍帧数据,将比yuv->rgb更恐怖的耗时间。实际的情况真是
令人沮丧,原本优化到32fbs了,加上deblock后直接降到16fbs。
优化分析:
(1)读取和写入内存会占大部分时间,不过这部分没什么好优化的。
(2)计算eq_cnt,这部分计算量很小,也不必在意
(3)从v[1]-v[8]中找出最大的最小的值
max = MAX(s[1],MAX(s[2],MAX(s[3],MAX(s[4],MAX(s[5],MAX(s[6],MAX(s[7],s[8])))))));
min = MIN(s[1],MIN(s[2],MIN(s[3],MIN(s[4],MIN(s[5],MIN(s[6],MIN(s[7],s[8])))))));
xvid给了两种方法计算MAX和MIN
#define MIN(X, Y) ((X)<(Y)?(X):(Y))
#define MAX(X, Y) ((X)>(Y)?(X):(Y))
#define FAST_MAX(x,y) ((x) - ((((x) - (y))>>(32 - 1)) & ((x) - (y))))
#define FAST_MIN(x,y) ((x) + ((((y) - (x))>>(32 - 1)) & ((y) - (x))))
第二种方法耗4条指令。
如果用汇编则只需3条指令
mov r1,r2 // r1 = max(r2,r3)
cmp r3,r1
movgt r1,r3
(4)计算s[1]-s[8],公式中有一些重复的计算,可以先计算重复部分后整体代换。
这些优化的都是耗时不太大的部分,真正耗时的是内存的存取部分。可以根据图像质量的状况适当减小计算的点数。标准中每次平均计算都取10点写8点,实际可以读8点写6点。
(guanchanghui) |