第一点，请先确认你自己是否对运动估计模块里里外外的理论，算法和整体结构，是否真的已经有足够的了解和掌握。
不要自己看书的时候，感觉自己已经啥都明白，结果自己上手做项目时直接傻掉，个人觉得陶渊明式好读书，不求甚解学习法，恐怕在算法优化领域行不大通。也不要一叶障目不见泰山，只知道模块内部一个个小点，对整个模块缺乏足够的整体意识和宏观把控。
比如说我问你，编码器什么时候需要进行运动估计，运动估计模块的输入是什么，输出是什么？运动估计的结果准确与否会影响哪些东西？现在常用的基于块匹配的搜索是否可以替代，最佳MV如何评判？如何判断你得到最佳MV是否能准确代表实际运动？如何确定你需要的快速搜索算法？运动搜索窗大小如何设置？多参考帧下运动矢量如何搜索？
如果你对于上面这些问题，都已经心中有数，那便可以开始考虑第二点。如果还有不明白的地方，建议还是先补一下基础知识吧。
第二点，需要确定现有编码器运动估计模块可优化的点有哪些。
比如你应当先设计实验摸底测试一下，目前运动估计模块的性能究竟是个什么水平。可以用profile工具，比如Window上的Intel Vtune，Linux上的perf等来测试运动估计模块里面的热点函数。
也可以选择一些典型测试序列，在开启和关闭现在运动估计已有算法时的编码器性能变化。也可以全搜索或者开源编码器对比一下算法复杂度和搜索结果。
或者使用码流分析软件看看你的码流中每个帧间实际的MV值范围，最大和最小分别有多大。
这样的话，你大致可以确定，现在的编码器运动估计模块可优化的点在哪里。是应当用指令集，多线程技术来提升搜索速度要紧，还是用快速算法提升性能优先。当然，如果你发现目前运动估计的代码逻辑和设计本身很挫，也可以考虑优化优化代码。
第三点，在确定优化点以后，就要去调研和查资料，看看同行和业界有没有已经针对这个点做过一些优化，都有哪些优化的方案，做到了什么程度和水平，这些有什么不足。
运动估计也少说有30年了，前前后后对它优化的方法多如牛毛，你是否有"虽千万人吾往矣"的勇气和魄力，你是否有"不畏浮云遮望眼"的功力和本事，值得思考。
第四点，根据调研结果，开始设计合适的的优化方案，并写代码进行实现。你是决定从整像素的快速搜索算法入手呢，还是打算对搜索窗大小自适应决策进行开刀，或者你要提前终止块匹配搜索过程，还是觉得子像素插值算法可以更快，请说明你的理由，并给出你的方案。
好点子也不是不能灵光乍现，但多数人的多数时候还是要借鉴和参考。教员曾在《反对本本主义》中说过，没有调查就没有发言权，同样，做编解码器算法优化，没有充分的调研，优化可能也无从谈起。
第五点，充分进行优化前后的性能对比测试，对测试数据进行分析和归纳整理。重点关注异序列的异常数据。
最后，给出优化测试结论和报告，修改代码提交评审
扫一扫
2485
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
