EDN首页   博客首页

1

关于投票
视频解码优化[转]
视频解码优化

以下通过剖析一些经验来了解视频解码优化
1  在嵌入式系统中实现MPEG4的视频解码
有两种方法可行
(1)采用ffmpeg(mplayer 的核心就是采用ffmpeg),然后对ffmpeg mp4解码优化

1)对IDCT汇编化,并优化VLD的实现   ->inline&汇编化
2)根据ARM9 cache & cache line的大小做MB的分组,使得每次可以同时处理多个MB
  即 对多个MB在一个循环内做VLD--->IDCT-->MC--.......  ->耦合
3)优化关键代码段的内存访问(MC)    ->inline&汇编化
4)不要使用FFmpeg内置的img_convert()做yuv2rgb转换  ->inline&汇编化
5)对解码库做ARM指令集优化    ->体系结构优化
  configured ffmpeg with cpu = ARMV4L would give you a better performance
  If you have IPP,you can enable it, you can obtain huge enhancement
  IPP="Intel"? Integrated Performance Primitives intel高性能构件库 (only for xScale)
 
(2)用xvid来做,ffmpeg包含的解码库太多,如果你只做MPPEG-4解码,何必用这么复杂的库?
btw,在嵌入式系统中最好用0.9.2版的xvid。
因为1.1.0的版本包含了很多AS的特性,通常在嵌入式系统中都不需要用,并且也不容易实现。
要自己做编码算法的话,不能总想依赖别人,最好还是需要自己花
功夫去实现和优化。因此我觉得从实际出发的话,XVID0.9.2版的比1.1.0的好。
实际上,通常在主频400MHz的平台上,要优化XVID的算法达到CIF实时解码也还是很容易的,最多就一个多月
2  视频解码流程对解码带来的影响
视频解码优化一般 代码量大,而且源代码往往是从其他地方获取得到的,所以阅读比较困难,更别说优化了,最近在优化realVideo,有几点心得:
1)阅读代码前必须先熟悉流程,抓住关键的点,比如视频解码不外乎熵解码,反量化,反变换,插值,重建,滤波,参考帧插入等。
把握住这几个点,可以将代码很快分离出来。
2)分析解码流程,了解解码需要的最小buffer是多大,各个buffer 的位宽多大。
3)根据已经知道的流程,跟踪代码buffer流向,是否存在多余的内存拷贝。想办法将buffer减少,经验说明,减少buffer带来的速度上的提升远大于局部算法的优化。 ->耦合
4)观察程序结构顺序是否合理,不合理的程序结构会导致buffer增大。
   这两天研究视频解码顺序,发现先插值后做反变换要比先做反变换再做插值效率要高许多,原因是插值后的位宽是8bits,而往往反变换后是9bits,所以在重建之前要保存插值后的值要比保存反变换后的值要省一半的空间,这样在重建时访问的内存就少很多了。据我了解,大部分高效率的解码器都是先插值再反变换,而且变换后马上做重建,这样既减少内存使用,也避免内存访问抖动太厉害,最终减少缓存不命中。 ->修改解码流程 耦合
3   cache机制对解码带来的影响
先看 http://www.hongen.com/pc/diy/know/mantan/cache0.htm
写透(直写式)和写回(回写式)有着截然不同的操作,在不同的场合,不同的内存块使用不同的回写策略(如果你的系统可以实现的话)要比使用一种策略要高效得多。具体一点,对于反复存取的内存块置成写回,而把一次写入而很长时间以后再使用的内存置为写透,可以大大提高cache的效率。
第一点很容易理解,第二点就需要琢磨一下了,由于写透的操作是,当缓存有该地址的数据时同时更新缓存和主存,当缓存没有该地址数据直接写主存,忽略缓存。当该地址的数据很长时间后才被使用到,那么在使用的时候该数据肯定不在cache中(被替换了),所以不如直接写入主存来得直接;
相反,如果使用写回操作,当 cache中有该地址数据,需要更新该数据,设置dirty位,很长时间后再使用该数据或被替换的时候才将其刷进主存,这有占了茅坑不拉屎的嫌疑;而当 cache没有该地址数据时,情况更糟糕,首先需要将相应的主存数据(一个cache line)导入cache,再更新数据,设置dirty位,再等待被刷回内存,这种情况不仅占用了cache的空间,还多一次从主存中导入数据的过程,同样占据总线,开销很大。至于为什么要先从主存中导入数据,是因为cache往主存回写数据时是按照一个cache line 单位来写的,但被更新的数据可能没有一个cache line这么多,所以为了保证数据一致性,必须先把数据导入cache,更新后再刷回来。
对于很多视频解码来说,帧写入过程是一个一次性的动作,只有在下一次作为参考帧时才会被使用到,所以帧缓冲内存可以设置为写透操作,而下一次使用它的时候很可能是作为参考帧来使用,而作为参考帧不需要反复的存取,只需一次读操作就可以了,所以效率并不会因为不经过cache而降低。实验证明该方法可以使 mpeg4 sp解码提高20-30%的效率。
相似的内容cache操作的小技巧还有prefetch操作,prefetch操作是将主存的数据导入cache而期间cpu不需要等待,继续下一条指令的执行,如果下一条指令也是总线的操作,那么就必须等待prefetch完成以后再开始。所以,在使用该指令时,在prefetch指令后面插入尽可能大于一次缓存不命中所需要的clock数对应的指令,那么prefetch与其后面的指令可以并行执行,从而省去了等待的过程,相当于抵消缓存不命中的损失。当然,如果插入的指令太多而cache太小,有可能prefetch的数据进入cache 后又被替换掉了,所以,这需要自己去评估。 ->cache优化
4  总结
IDCT是视频解码中关键步骤中的第一步,目前一般采用快速算法来做,如chen-wang 算法,c语言和汇编的效果差别还是比较大的。
对一个8x8的block做idct做变换,如   
for (i = 0; i < 8; i++)
 idct_row (block + 8 * i);
for (i = 0; i < 8; i++)
 idct_col (block + i);
把他汇编后,主要是可以减少存储器带宽,提高存储效率,避免无谓的内存读写。
mplayer 在此方面做了很多努力,针对armv4(s3c2440属于armv4l架构)的相关文件放在dsputil_arm_s.S文件中。但遗憾的是,它里面有一条指令PLD,cache预取指令2440是不支持的。PLD指令属于enhanced DSP指令,在armv4E(E 既代表enhanced DSP)才被支持,因此在我们orchid上跑的代码必须注释掉这条指令,否则编译不过
再把话题转回来,在IDCT之前,视频压缩流通过VLD(variable lenght decode)变长解码得到DCT数据。
这部分工作一般是通过查表来加速性能,所有的编码表会预先存起来。而取视频比特流的代码通常是宏,
通过宏的扩展来达到和汇编同样的效果。
在IDCT后还有关键的运动补偿和色彩空间转换两个步骤。对运动补偿的加速也是通过汇编化,其代码也同样放在
dsputil_arm_s.S 有必要一提的是在这部分,如果有SIMD指令将会极大的提高它的速度。
color space转换是解码输出后的最重要的一步。在嵌入式系统中,一般都是采用rgb565既16bit来表示一个像素的色彩。
一个8x8的block,它的yuv(420格式)表示如下,
YYYYYYYY
YYYYYYYY
YYYYYYYY
YYYYYYYY
UUUUUUUU
VVVVVVVV
注意它的值是8bit的,通过装换方程计算,可以得到像素值。在实现中通常采用查表来加速计算,对于每一个Y,U,V都有
一个对应表。对于1个320x240的video,共76800像素。如果每个像素在这个转换中节省10个cycle,那save下来的cpu还是相当可观的。
当色彩空间转换完后,就是通过把这个picture copy到framebuffer的内存里,这里存在一大片的copy时间。有两方面可以注意,
一是有人实现过把转换后的内存直接往framebuffer送,减少最后所需的copy过程,这个idea确实不错,但是需要一些技巧去实现
二是copy这个过程本省也是可以加速的,在armv5以上的体系结构里,cpu----cache---memory,其中cache和memory的宽度是32位,
但cpu和cache的bus width确是64位,用32位的成本实现了64位的存储器。如果这个能被使用,那么理论上,copy速度可以加倍。
在PC机上,一般我们的应用程序会有fastmemorycopy这个函数,它们是用simd等特殊指令来实现,在armv5上则是通过它的总线宽度来加速
在s3c2440上不可用:( 它是v4架构。
总的来说,
(1)算法级的优化基本用无可用,ffmpeg/mplayer已经实现的相当不错,除非自己实现一个新的decoder;
(2)在代码级,主要是通过关键代码的inline(宏,inline函数)和汇编来加速。这部分在arm平台还是有一些潜力可挖
(3)硬件级,在这一层,cpu的体系结构决定指令集、cache的形式和大小等。如指令集是否有enhanced DSP指令、SIMD指令
,cache是否可配置、cache line大小,这些都会影响代码级和算法级的优化
(4)系统层优化,之所以把它放在最后一层,是由于它建立在整个系统之上,只有对整个系统包括硬件和软件有深刻的理解才能做到。
纵观优化,其实质是尽可能的去除冗余计算,最大化的利用系统硬件资源。
对于RISC架构的cpu来讲,先天不足的就是需要比较大的存储器带宽(因为RISC的指令都是基于寄存器的,必须把操作数都load到内存才能计算),
cpu资源被过多的使用在内存的read和write。
以以下代码为例,它是解码输出后,把yuv空间装换成rgb空间的一个片断
000111c :       
    111c:       e92d4ff0        stmdb   sp!, {r4, r5, r6, r7, r8, r9, sl, fp, lr}
    1120:       e1a0a000        mov     sl, r0
    1124:       e5900038        ldr     r0, [r0, #56]
    1128:       e1a0c001        mov     ip, r1
    112c:       e3500004        cmp     r0, #4  ; 0x4
    1130:       e24dd034        sub     sp, sp, #52     ; 0x34
    1134:       e1a00002        mov     r0, r2
    1138:       e1a01003        mov     r1, r3
    113c:       0a00055d        beq     157c
    1140:       e59d2058        ldr     r2, [sp, #88]
    1144:       e3520000        cmp     r2, #0  ; 0x0
    1148:       d1a00002        movle   r0, r2
    114c:       da00055b        ble     1574
    1150:       e59d3060        ldr     r3, [sp, #96]
    1154:       e58d1030        str     r1, [sp, #48]
    1158:       e5933000        ldr     r3, [r3]
    115c:       e59f2434        ldr     r2, [pc, #1076] ; 1598 <.text+0x1598>
    1160:       e0213193        mla     r1, r3, r1, r3
    1164:       e58d3018        str     r3, [sp, #24]
    1168:       e59d305c        ldr     r3, [sp, #92]
    116c:       e58d1000        str     r1, [sp]
    1170:       e5933000        ldr     r3, [r3]
    1174:       e79a1002        ldr     r1, [sl, r2]
    1178:       e58d301c        str     r3, [sp, #28]
    117c:       e5903008        ldr     r3, [r0, #8]
    1158:       e5933000        ldr     r3, [r3]
    115c:       e59f2434        ldr     r2, [pc, #1076] ; 1598 <.text+0x1598>
    1160:       e0213193        mla     r1, r3, r1, r3
    1164:       e58d3018        str     r3, [sp, #24]
    1168:       e59d305c        ldr     r3, [sp, #92]
    116c:       e58d1000        str     r1, [sp]
    1170:       e5933000        ldr     r3, [r3]
    1174:       e79a1002        ldr     r1, [sl, r2]
    1178:       e58d301c        str     r3, [sp, #28]
    117c:       e5903008        ldr     r3, [r0, #8]
    1180:       e59c4008        ldr     r4, [ip, #8]
    1184:       e590e000        ldr     lr, [r0]
    1188:       e59c2000        ldr     r2, [ip]
    118c:       e5900004        ldr     r0, [r0, #4]
    1190:       e59cc004        ldr     ip, [ip, #4]
    1194:       e58d3014        str     r3, [sp, #20]
    1198:       e1a011c1        mov     r1, r1, asr #3  ;h_size
    119c:       e3a03000        mov     r3, #0  ; 0x0
    11a0:       e58d4010        str     r4, [sp, #16]
    11a4:       e58d2004        str     r2, [sp, #4]
    11a8:       e58de020        str     lr, [sp, #32]
    11ac:       e58d000c        str     r0, [sp, #12]
    11b0:       e58dc008        str     ip, [sp, #8]
    11b4:       e58d1028        str     r1, [sp, #40]
    11b8:       e58d3024        str     r3, [sp, #36]
    11bc:       e1a08003        mov     r8, r3
    .................................................
    .................................................
我们可以发现在这个片断中有太多的ldr(load, read from memory)和str(store, wirte to memory)
而且过多的load和str还影响了cpu和memory之间的cache的效率,形成cache抖动。当发生cache miss时,
cahce控制器花了大力气把内容从memory搬到cache,但是没怎么用这个entry马上又被替换掉。如果运气不好,
cache就一直这样"抖动"。
在解码过程中,各个模块都各自为战,都各自去占比较大的memory带宽
如何减少这种无用的行为呢?必须让关键代码适应硬件体系结构,把数据流相关的代码耦合在一起。
很多代码通过模块化得到了优秀的可读性和可扩展性。鱼与熊掌不可兼得,耦合在一起的代码会显得比较晦涩难懂。
ffmpeg/mplayer在这方面作了一个比较好的tradeoff。
1、2、3的知识摘自网上,要比较好的理解以上内容需要一些视频编、解码的知识。

系统分类: 自由话题
用户分类: Linux
标签: 无标签
来源: 转贴
发表评论 阅读全文(216) | 回复(0)

2

关于投票
xvid的学习

xvid有两种编码方式:single pass和twopass 
single pass模式编码简单,速度也快,但最终效果不如twopass。 
twopass就是视频压制需要经过两次编码,分别为twopass-1st pass(简称1pass)和twopass-2nd pass(简称2pass) 
1pass时,编码器会用最高质量编码采集可供第2次运算参考的画面信息,而在2 pass时。编码器会根据第一次压缩获得的信息和用户指定的文件大小,自动分配比特率,使需要高流量的运动画面分配到更多的空间,更高的比特率来保证画面质量。相对的,对于那些不包含太多运动信息的静态画面则用较低的比特率。追求画质的朋友当然会选择这种方式,但运算比single pass更费时。 

接下来介绍一些基本概念: 
Q值——量化值,它被用来描述1帧的质量,每帧都有一个Q值,取值范围在1-31之间。Q值越小,画质越好,比特率越大 
I-frame——关键帧,常被缩写为IF。关键帧是构成一个帧组的第一帧。IF保留了一个场景的所有信息 
P-frame——未来单项预测帧,缩写为PF,只储存与之前一个已解压画面的差值 
B-frame——双向预测帧,缩写为BF,除了参考之前解压的画面以外,也会参考后一帧的画面信息 

 

编码流程: 

 

各变量的设置:创建xvid_enc_frame_t和xvid_enc_stats_t,分别用于传入参数和统计编码结果。 

具体过程: 

设置传入图像数据和图像色彩空间 

设置传出的码流 

设置vol的标志 

设置帧的编码类型 

设置量化因子 

设置运动估计算法集合 

设置vop的标志 

 

编码器提供的函数 

1, xvid_global(NULL, XVID_GBL_INIT, &xvid_gbl_init, NULL); 

含义:根据cpu的特性使用相应汇编优化的函数 

 

2, xvid_encore(NULL, XVID_ENC_CREATE, &xvid_enc_create, NULL); 

含义:初始化编码器。 

具体过程: 

创建编码器句柄,并根据传入的参数设置各变量的值,并且分配要使用的内存,用于存放重建帧,参考帧(1/2像素精度)。以及各种临时变量。并且做好码率控制的初始化。 

 

3, xvid_encore(enc_handle, XVID_ENC_ENCODE, &xvid_enc_frame, &xvid_enc_stats); 

目的:编码一帧 

具体过程: 

初始化写码流。 

如果有必要,转换色彩空间,并且把原始图像拷贝到有边框的图像空间,但是没有扩展边框。 

将重建帧交换成参考帧 

从帧队列中获取当前帧 

设置Encoder结构体的current结构体的vol_flags,vop_flags,motion_flags,fcode,bcode和quant字段。 

调用call_plugins,在里面调用rc_single_before做码率控制的初始化,以及对current结构体的其他变量进一步设置 

通过帧号或者MEanalysis函数分析来确定编码类型,并且根据用户的设置作修正。 

MEanalysis的原理是,如果某个宏块的残差的sad大于该宏块的平均值的偏离,那么使用intra方式,否则使用inter方式,然后对这些宏块进行统计,得到整帧的编码方式。 

 

如果编码类型是I_VOP 

设置Encoder->mbParam->vol_flags 

设置Encoder->mbParam.par 

根据vol_flags设置vop_flags 

调用FrameCodeI以I帧的方式编码 

调用call_plugins,在里面调用rc_single_after,进行码率控制。 

 

如果编码类型是P_VOP 

用mbParam.vol_flags固定住pEnc->current->vol_flags 

调用FrameCodeP以P帧的方式编码 

调用call_plugins,在里面调用rc_single_after,进行码率控制。 

}// xvid_encore 

 

4, static int FrameCodeI(Encoder * pEnc, Bitstream * bs) 

目的:将一帧图像编码成一个I帧 

具体过程: 

以XVID_PLG_FRAME参数调用call_plugins,该函数目前的作用是设置dquant,可以在该函数中设置最好质量。 

调用SetMacroblockQuants,为每个宏块设置量化因子,所以也可以在这里设置最好质量 

调用BitstreamWriteVolHeader,写vol 

调用set_timecodes,设置时间编码。 

调用BitstreamPad,填充bit至字节对齐 

调用BitstreamWriteVopHeader,填写vop头 

 

依次读取每一个宏块,进行编码 

调用CodeIntraMB设置编码模式为intra,将所有和运动有关的变量设为0 

调用MBTransQuantIntra进行变换编码 

调用MBTrans8to16将像素的表示方法从8bit扩大到16bit 

调用MBfDCT对像素进行变换编码 

调用MBQuantIntra对dct系数进行intra方式的量化 

调用MBDeQuantIntra对dct系数进行intra方式的反量化 

调用MBiDCT将恢复的dct系数进行反变换 

调用MBTrans16to8将恢复的16bit像素饱和到8bit,组成重建宏块 

}//MBTransQuantIntra 

 

调用MBPrediction作acdc预测 

调用get_dc_scaler函数得到量化系数 

调用predict_acdc得到预测方向以及在该预测方向上的和当前块的同一量化水平的预测值 

调用calc_acdc_bits以确定是只使用DC预测,还是DCAC预测。原理是分别作DC预测和DCAC预测,分别计算在这2种情况下需要的码流长度,以确定哪种方式更节约码流。 

调用CodeCoeffIntra_CalcBits,用于确定各种方式下的码流长度 

根据预测模式的不同,恢复成相应的系数 

最后计算该宏块的cbp 

}//MBPrediction 

 

调用MBCoding将宏块编制成码流 

调用CodeBlockIntra将intra宏块编制成码流 

编码mcbpc 

编码ac预测标记 

编码cbpy 

对于6个块里的每个块 

首先编码DC系数 

调用CodeCoeffIntra对剩下的63个系数进行编码 

}//CodeBlockIntra 

}//MBCoding 

 

}//依次读取每一个宏块,进行编码 

 

填充bit,直到字节对齐 

 

 

5, static int FrameCodeP(Encoder * pEnc, Bitstream * bs) 

含义:将一帧图片编码成P帧 

具体过程: 

如果参考帧还没有设置边框,那么就调用image_setedges设置边框 

如果需要半像素运动估计,那么就调用image_interpolate进行插值 

将一帧填充边框后的参考帧,分成8*8的小块,对于每个小块进行插值,如下: 

调用interpolate8x8_halfpel_h进行水平插值 

调用interpolate8x8_halfpel_v进行垂直插值 

调用interpolate8x8_halfpel_hv进行对角线插值 

用参数XVID_PLG_FRAME调用call_plugins,该函数目前的作用是设置dquant,可以在该函数中设置最好质量。 

调用SetMacroblockQuants,为每个宏块设置量化因子,所以也可以在这里设置最好质量 

调用MotionEstimation做运动估计 

使用MotionFlags变量保存要使用的运动算法集合 

使用skip_thresh保存要达到skip模式的阀值 

使用Data保存运动估计要用到的相应变量 

对于每个宏块,依次执行如下操作 

调用sad16v计算本宏块与参考帧对应位置宏块的亮度的残差,将其保存在pMB->sad16中,并按照4个块的方式分别存放pMB->sad8[0-3]中 

用sad00记录最大亮度块残差的4倍 

如果还需要考虑色差块的因素 

调用sad8两次,分别计算u分量和v分量的残差,都加入pMB->sad16中,并且也加入sad00中 

如果该宏块的量化差值为0,并且sad00又没有超过skip模式的阀值 

如果已经考虑了色差因素,或者使用xvid_me_SkipDecisionP确认符合skip模式。 

调用ZeroMacroblockP将其编码为skip模式,并置标记pMB->mode = MODE_NOT_CODED 

根据采用的运动估计算法不同,做相应的设置 

调用SearchP做该宏块的运动估计 

确定是否使用inter4v模式,并记录之 

调用get_range确定运动搜索的范围,并记录在Data中 

调用get_pmvdata2,以获得左,上,右上的运动向量,以及它们对应的sad,存入pmv[1-3]和Data->temp[1-3]。然后计算它们的中值,并且存放于pmv[0],并且把最小的sad存放于Data->temp[0] 

设置Data的当前宏块的yuv字段。设置Data->RefP[0-5]为参考帧的同一宏块的整像素y,水平半象素y,垂直半象素y,对角线y,u,v。 

设置Data->lambda16和Data->lambda8,其含义可能是运动向量对带宽的占用折合到sad的值 

设置qpel和方向 

如果采用qpel,调用get_qpmv2计算用qple方式下的估计中值,存入ata->predMV;否则,Data->predMV为0。 

调用d_mv_bits计算mv需要的编码bit,用于修正pMB->sad16和pMB->sad8[0],并将Data->iMinSAD[0-4]设置为pMB->sad16和pMB->sad8[0-3],也就是0向量对应的各SAD。 

如果不采用率失真决策模型,并且不是当前帧的第一宏块,那么使用一种方法设置阀值threshA,否则阀值threshA为512。 

 

调用PreparePredictionsP,对pmv作进一步的设置,做运算前的准备。 

设置pmv[0]为0向量 

设置pmv[1]为中值向量的偶数值 

设置pmv[2]为参考帧相同位置宏块的第0块运动向量的偶数值 

如果该宏块有左边宏块,设置pmv[3]为左边宏块的第1块的运动向量的偶数值,否则为0 

如果该宏块有上面宏块,设置pmv[4]为上面宏块的第2块的运动向量的偶数值,否则为0 

如果该宏块有右上宏块,设置pmv[5]为右上宏块的第2块的运动向量的偶数值,否则为0 

如果该宏块有右下宏块,设置pmv[6]为参考帧的相同宏块的右下宏块的第0块的运动向量的偶数值,否则为0。 

}//PreparePredictionsP 

 

如果使用inter4v,设置CheckCandidate为CheckCandidate16,否则设置为CheckCandidate16no4v 

 

逐一检查mpv[1-6]这六个最可能运动向量,如果发现他们与以前的运动不同,就调用CheckCandidate做运动估计,过程如下: 

检查要做运动估计的运动向量是否越界 

通过该运动向量获得所指向数据块的指针 

调用sad16v,记录下4个8*8块的SAD值,存入data->temp[0-3]中,并将他们的和存入临时变量sad中。 

对sad和data->temp[0]做基于运动向量的修正。 

如果要考虑色差因素,调用xvid_me_ChromaSAD计算额外的SAD,累加至sad中。 

如果sad小于data->iMinSAD[0],那么设置data->iMinSAD[0],data->currentMV[0],和data->dir。注意,此时的data->dir记录的不是钻石搜索的方向,而是当前向量是pmv数组的第几个元素。 

逐一检查data->temp[0-3],如果他们小于data->iMinSAD[1-4],那么修改data->iMinSAD[1-4]和data->currentMV[1-4] 

}//CheckCandidate 

 

如果当前最优运动向量,即Data->iMinSAD[0],小于threshA?或者当前最优运动向量等于参考帧相同位置宏块的运动向量,并且对应的SAD值又比他的小? 

就不再做inter4v的搜索 

否则,就做inter4v的搜索 

使用make_mask逐一检查存放于pmv的所有运动向量,察看是否位于欲搜索的钻石形的顶点。如果是,则在mask变量中标记之。 

根据MotionFlags确定使用的搜索函数,根据当前设置,MainSearchPtr = xvid_me_AdvDiamondSearch 

调用xvid_me_AdvDiamondSearch进行搜索,过程如下: 

bDirection既表明了上次尝试的方向,又表明本次可以尝试的方向 

x,y为钻石搜索的位置的中心点坐标 

for(;;) 

如果可以尝试左边,那么调用CheckCandidate尝试左边 

如果可以尝试右边,那么调用CheckCandidate尝试右边 

如果可以尝试上边,那么调用CheckCandidate尝试上边 

如果可以尝试下边,那么调用CheckCandidate尝试下边 

如果有更好的方向 

bDirection = 更好的方向 

如果更好的方向是左右方向,那么测试该位置的上下方向 

否则,那么测试该位置的左右方向 

如果这次又找到了更好的方向 

将更好的方向累加到bDirection 

将更好的位置存入x,y 

否则 

根据去搜索临近未搜索的点,具体规则如下: 

如果bDirection = = 2,表明搜索方向是趋向右边的,那么搜索当前中心点的右上点和右下点。 

如果bDirection = = 1,表明搜索方向是趋向左边的,那么搜索当前中心点的左上点和左下点。 

如果bDirection = = 2+4,表明搜索方向是趋向右上的,那么再搜索当前中心点的左上点,右上点和右下点。 

如果bDirection = = 4,表明搜索方向是趋向上边的,那么搜索当前中心点的左上点和右上点。 

如果bDirection = = 8,表明搜索方向是趋向下边的,那么搜索当前中心点的左下点和右下点。 

如果bDirection = = 1+4,表明搜索方向是趋向左上的,那么再搜索当前中心点的左下点,左上点和右上点。 

如果bDirection = = 2+8,表明搜索方向是趋向右下的,那么再搜索当前中心点的左下点,左上点和右上点。 

如果bDirection = = 1+8,表明搜索方向是趋向左下的,那么再搜索当前中心点的左上点,左下点和右下点。 

否则的话,则认为本轮搜索没有找到更好的点,那么再搜索当前中心点的左上点,左下点,右上点,右下点。 

如果没有找到更好的方向,从函数中返回 

更新bDirection为更好的方向 

更新x,y为更好的位置 

}//for(;;) 

 

}//xvid_me_AdvDiamondSearch 

 

如果运动估计算法使用了XVID_ME_EXTSEARCH16,那么 

设置startMV = Data->predMV 

设置backupMV为当前最佳运动向量 

如果startMV和backupMV不相等 

调用CheckCandidate计算位置为startMV的SAD 

调用xvid_me_DiamondSearch做以startMV为起点的搜索,过程如下: 

for(;;) 

如果可以尝试左边,那么调用CheckCandidate尝试左边 

如果可以尝试右边,那么调用CheckCandidate尝试右边 

如果可以尝试上边,那么调用CheckCandidate尝试上边 

如果可以尝试下边,那么调用CheckCandidate尝试下边 

如果没有更好的方向,退出 

bDirection = 更好的方向 

x,y = 更好的位置 

如果更好的方向是左右方向,那么测试该位置的上下方向 

否则,那么测试该位置的左右方向 

如果这次又找到了更好的方向 

bDirection += 更好的方向 

x,y = 更好的位置 

}//xvid_me_DiamondSearch 

 

将这次搜索结果和上次搜索结果比较,记录最佳的SAD和位置。 

}//如果startMV和backupMV不相等 

 

设置startMV = {1,1} 

设置backupMV为当前最佳运动向量 

如果startMV和backupMV不相等 

调用CheckCandidate计算位置为startMV的SAD 

调用xvid_me_DiamondSearch做以startMV为起点的搜索,过程如下: 

将这次搜索结果和上次搜索结果比较,记录最佳的SAD和位置。 

}//如果运动估计算法使用了XVID_ME_EXTSEARCH16 

}//否则,就做inter4v的搜索 

 

如果没有采用1/4像素运动估计算法 

如果采用了XVID_ME_HALFPELREFINE16算法 

调用xvid_me_SubpelRefine 

按顺时针方向8次调用CheckCandidate16,得到最好的1/2像素位置 

否则 

略 

 

如果当前SAD足够小,那么inter4v = 0 

如果采用inter4v 

4次调用Search8来搜索4个8*8块的最佳运动向量,每一次搜索的规则如下: 

如果采用1/4像素运动估计,略。否则 

调用get_pmv2取得本块的中值 

计算第一块以外快的d_mv_bits 

用Data->lambda8修正该块当前的SAD,但是第0块是不用修正的。 

如果使用了XVID_ME_EXTSEARCH8 | XVID_ME_HALFPELREFINE8 | XVID_ME_QUARTERPELREFINE8,那么 

Data->RefP[0-3] = 参考帧的整像素,水平半象素,垂直半象素,对角线半象素的对应宏块的对应块的起始地址。 

Data->Cur = 当前帧的当前宏块的当前块的起始地址 

利用get_range得到运动搜索的范围 

根据MotionFlags的指示,设定运动估计MainSearchPtr的算法,当前设置为MainSearchPtr = xvid_me_AdvDiamondSearch。 

调用xvid_me_AdvDiamondSearch做运动估计,其中做SAD的函数是CheckCandidate8,该函数类似于CheckCandidate16 

如果不采用1/4像素运动估计,并且又采用了XVID_ME_HALFPELREFINE8,那么调用xvid_me_SubpelRefine 

按顺时针方向8次调用CheckCandidate8,得到最好的1/2像素位置 

如果采用了1/4像素运动估计,略 

}// XVID_ME_EXTSEARCH8 | XVID_ME_HALFPELREFINE8 | XVID_ME_QUARTERPELREFINE8 

 

如果采用1/4运动估计 

略 

否则 

记录pMB->pmvs[block] = 当前找到的最佳位置与预测位置的差值 

 

将这次的搜索存入相应OldData的字段,以及pMB的相应字段 

}// Search8 

如果考虑色差的因素,并且又不考虑率失真算法 

根据是否采用1/4像素运动估计算出色差的运动向量 

计算u,v的SAD,将其作为Data->iMinSAD[1]的修正 

} //如果采用inter4v 

否则,Data->iMinSAD[1]为足够大的值 

}//SearchP 

 

调用ModeDecision_SAD确定该宏块的类型 

判断该宏块要采取的编码方式,MODE_INTER,MODE_INTER4V,MODE_NOT_CODED,MODE_INTRA 

调用motionStatsPVOP做一些统计工作 

具体过程略 

}//对于每个宏块,依次执行如下操作 

做一些最后的设置 

}//MotionEstimation 

 

调用set_timecodes设置时间戳 

调用BitstreamWriteVopHeader写VOP头 

具体过程略 

 

对于每一个宏块,依次执行如下操作 

如果该宏块的编码模式是MODE_INTRA或者MODE_INTRA_Q 

调用CodeIntraMB设置编码模式为intra,将所有和运动有关的变量设为0 

调用MBTransQuantIntra进行变换编码 

调用MBCoding将该宏块编制成码流 

Continue 

 

调用MBMotionCompensation做运动补偿 

如果编码模式是MODE_NOT_CODED 

用参考帧的相应宏块替代当前帧的当前宏块 

Return 

 

如果编码模式是MODE_NOT_CODED或者MODE_INTER或者MODE_INTER_Q 

如果mb->mcsel不为0 

做GMC的处理 

Return 

计算运动向量dx,dy 

调用compensate16x16_interpolate进行运动补偿 

如果采用1/4像素运动估计 

略 

否则,调用get_ref计算用于运动补偿的参考宏块的指针 

调用4次transfer_8to16sub做亮度块的运动补偿,使得临时数组里存放的是残差,而原始图像里存放的是参考快的数据。 

}//compensate16x16_interpolate 

计算出用于色差运动补偿的dx,dy 

}//MODE_NOT_CODED或者MODE_INTER或者MODE_INTER_Q 

 

否则,那就是MODE_INTER4V 

根据是否使用1/4像素运动估计,计算出4个色度块的运动向量 

以这4个运动向量为参数,调用4次compensate8x8_interpolate ,该操作类似于compensate16x16_interpolate,不同在于一次只计算一个块。 

计算出用于色差运动补偿的dx,dy 

 

调用CompensateChroma计算色差块的运动补偿 

调用interpolate8x8_switch2计算出u的插值 

调用interpolate8x8_halfpel_v或者interpolate8x8_halfpel_h或者interpolate8x8_halfpel_hv做实际的插值操作,或者直接返回 

调用transfer_8to16sub_c做u份量的运动补偿 

 

调用interpolate8x8_switch2计算出v的插值 

调用interpolate8x8_halfpel_v或者interpolate8x8_halfpel_h或者interpolate8x8_halfpel_hv做实际的插值操作,或者直接返回 

调用transfer_8to16sub_c做v份量的运动补偿 

}//CompensateChroma 

 

}//MBMotionCompensation 

 

如果需要编码,那么用MBTransQuantInter进行编码,并把结果返回给pMB->cbp 

调用MBfDCT进行宏块变换编码 

调用6次fdct 

 

调用MBQuantInter进行量化 

对于宏块里的每一块 

调用quant_h263_inter进行量化 

如果在量化后,前三个系数为0,并且系数的绝对值之和小于阀值,那么标记该块为全0块,将标记存入cbp。否则,标记为非全0块,也将标记存入cbp 

}//MBQuantInter 

 

调用MBDeQuantInter反量化 

确定要使用的反量化函数 

对于六个块里的每个块,如果cbp表示许可,都调用dequant_h263_inter反量化 

}//MBDeQuantInter 

 

调用MBiDCT做反离散余弦变换 

对于六个块里的每个块,如果cbp表示许可,都调用idct_int32反量化 

 

调用MBTrans16to8将恢复出的残差构成重建图像 

确定具体执行的函数,分为transfer_16to8copy和transfer_16to8add 

找到该宏块的y,u,v分量起始地址 

对于六个块里的每个块,如果cbp表示许可,调用相应得函数执行重建。 

}// MBTrans16to8 

}//MBTransQuantInter 

 

如果无残差,并且编码方式为MODE_INTER,并且帧方式是P帧,并且向量2分量都为0,那么可以考虑skip模式 

如果可以考虑skip模式,则做进一步检验,如果检验通过,那么 

编码模式为MODE_NOT_CODED,并且在码流里做标记 

Continue 

 

调用MBCoding将这个宏块写入码流 

写入非NOT_CODED标记 

调用CodeBlockInter写入码流 

编码mcbpc 

编码cbpy 

调用CodeVector编码运动向量 

对六个块,如果cbp只是需要编码,调用CodeCoeffInter进行编码 

}//CodeBlockInter 

}// MBCoding 

 

}//对于每一个宏块,依次执行如下操作 

 

更新fcode 

为下一帧的编码做简单的更新设置 

统计该帧编码长度 

}// FrameCodeP

系统分类: 自由话题
用户分类: 无分类
标签: 无标签
来源: 转贴
发表评论 阅读全文(237) | 回复(0)
总共 , 当前 /