经过十个月的努力，终于成功在DM365上实现了两路D1+两路CIF的H264编码，在DM368上实现了四路D1+四路CIF的H264编码。在整个开发过程中，有愤怒，有无奈，也有喜悦，聊记下一点粗浅的看法。
一流的硬件
应当说，365和368的运算能力还是比较强悍的，性价比不错。DM36x + TVP5158的设计方案看似合理，但整体感觉DM36x就是一个不成熟的CPU，完全不像是TI这样的大厂推出来的芯片：
1、 PRTCSS这个硬件模块几乎没有任何实用价值，最后还是被迫外加看门狗。
2、 宣称支持的网络启动要等下一个REVISION。
3、 链式DMA最后非得加上一个空的SLOT。
4、 RESIZER无法保证一定能正确完成数据的处理，必须一点点的尝试去调整参数。尤其在系统负担较重的时候，RESIZER经常会有数据丢失。
5、 TVP5158给出的数据不规则，需要在CPU端重新组织，由此导致了沉重的开销。
说实话，在进行开发之前完全没想过居然会有如此多的问题，在开发过程中常常有一种上当受骗的感觉，相当的不爽！！
二流的软件
如果说DM36x的硬件还算一流的话，那么TI的软件充其量也就是二流的水平。
在Davinci平台上，TI推销的是DVSDK这个开发套件，从2.0开始到现在，其规模越来越庞大，让人越来越难以理解。但是实际上，我们所需要的东西一直都只有那么一点，几百K而已。
DVSDK的设计思想也许是好的，把嵌入式的开发组件化，但TI最大的错误在于把复杂的配置工作甩给了用户来完成，大大加重了开发者的负担。一种比较好的方法应该是在自己内部维护这样一个工程，针对不同的应用可以快速裁剪出相应的版本进行发布。
比如对于H264编码来说，我们所需要的其实只是一个编码器，再根据定义好的接口实现外围的代码，几百K足矣，但在TI的方案里，我们被迫接受一个几百兆的软件包，相差1000倍啊！！！想想就觉得挺可笑的，这么庞大的方案，除了说明“我们是大厂，我们有能力开发这么大的软件包”之外，还能有什么用处呢？
更重要的是，这么庞大的东西，导致了效率的降低，同样做视频采集和编码，使用DVSDK的框架导致了至少5%的效率损失，对于DM368的四路双码流编码，本来就已经接近硬件的极限，这5%让人忍无可忍！！
三流的文档
TI的文档很多，如果打印成纸质的话，想来足以压倒一个人。但是它的文档质量让人难以恭维，且不说有多晦涩，可怕的是同一份文档，居然还有前后矛盾的说法，或者说在功能描述上说要配置某寄存器，但在后面却无论如何找不到这个寄存器的说明，最悲哀的是还有部分说明和硬件的实际配置无法对应！！
还有一些关键性文档的缺失，比如HDVICP，MJCP这两个硬件模块的详细说明，迄今为止遍寻不获。
无奈~~~