免费静态网站托管平台,南宁建站模板厂家,关键词筛选工具,手机排行榜2022前十名最新以下通过剖析一些经验来了解视频解码优化 1. 在嵌入式系统中实现MPEG4的视频解码 有两种方法可行 (1)采用ffmpeg(mplayer 的核心就是采用ffmpeg)#xff0c;然后对ffmpeg mp4解码优化 1).对IDCT汇编化,并优化VLD的实现 -inline汇编化 2).根据ARM9 cachecache…以下通过剖析一些经验来了解视频解码优化 1. 在嵌入式系统中实现MPEG4的视频解码 有两种方法可行 (1)采用ffmpeg(mplayer 的核心就是采用ffmpeg)然后对ffmpeg mp4解码优化 1).对IDCT汇编化,并优化VLD的实现 -inline汇编化 2).根据ARM9 cachecache 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 IPPIntel? Integrated Performance Primitives intel高性能构件库(only for xScale) (2)用xvid来做ffmpeg包含的解码库太多如果你只做MPPEG4解码何必用这么复杂的库. 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 在此方面做了很多努力针对armv4s3c2440属于armv4l架构的相关文件放在 dsputil_arm_s.S文件中。但遗憾的是它里面有一条指令PLDcache预取指令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的通过装换方程计算可以得到像素值。在实现中通常采用查表来加速 计算对于每一个YUV都有一个对应表。对于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 .text0x1598 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 .text0x1598 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在这方面作了一个比较好的trade-off。 1、2、3的知识摘自网上要比较好的理解以上内容需要一些视频编、解码的知识。 BTW:http://blog.csdn.net/weixianlin/archive/2008/05/01/2358035.aspx
