牢骚几句

Opencore不是一般的复杂，各个层次的调用，设计模式，插件技术，等等混合在一起使用。

庆幸能有sourceinsight用，否则，还真不知道从哪里看起。

 

 

接触opencore有了2个多月时间了，以前我自己做了一个系统，是用OpenMax1.2的。全年的时候公司项目经理考虑到移植性的问题，所以让我来负责采用这么个开放API协议的系统。原因是因为opencore也是采用OpenMax1.2来做codec层。

 

当时考虑的是挺好，可是后来在项目压力以及软硬件条件的局限下，这个系统就不那么的有兼容性和扩充性了。

 

我具体的做法是参考Bellagio（一个开源的Openmax IL实现），然后在此基础上交叉编译到我们自己的板子上。结果发现这个实现在写一个component的时候实在痛苦，而且那些代码看的巨痛苦，所以做了若干更改...经过无数个纠结的加班夜，终于将写一个component的代码行数从2000行减少到400行就可以搞定，其中有200行是重复代码，直接从以前的代码中copy过来即可。其他同事看两下以前的code，也能2天就写一个新的component，调试2天，基本一周就能运行起来。

 

而在此系统上，也运行了大量的应用，像mp3,midi,wav播放，mp4播放，手机电视，录像...。也还算稳定，跑个几千上万次没啥问题。

 

一年后回头一看，此时的code已经面目全非了。几乎看不出是从Bellagio改过来的了。

 

但是缺陷非常明显，就是兼容性太差，虽说是根据OpenMax 1.2的标准文档做出来的，但是由于所有的内容都是自己做，所以很多地方处理起来非常dirty，例如对于录音，每个buffer的大小就假定是4096了。

 

半年前公司要上android系统了，于是我很自然地要完成OpenMax系统移植的工作，这时候才发现兼容性是个致命的问题。

 

我发现无法维护一套code来同时运行以前的应用，以及在集成到opencore中。

 

于是，我主张重新在opencore框架下移植我们自己的codec。