关于DM368的resizer的使用问题

应该是DDR带宽不够的问题。在DM368上最多实现1路1080p30的编码，而且需要是连续模式（不是one shot mode）。

使用连续模式的话，最多只能得到2路输出。

而我们的项目需要3路输出，2路做编码，一路做LCD预览，所以只能用ss模式了。

我做了实验，ss模式下，最耗时的过程就是从capture得到的1080P的yuv422，转换成1080P的yuv420，这个过程很耗时，导致只编码一路h264，只能到10几帧。

如果是ss模式，在DM368上是无法实现你需要的应用的，主要还是DDR带宽的限制。你可以不编码，就做1080p422到420的转换，看时间是不是有减少。由于编码也需要访问DDR，这会导致IPIPE处理能力相应影响。

第三个分辨率能否用其他方式实现（不使用resizer）而使用连续模式。如果你使用1080p25帧的话，连续模式还是有希望的。但任何多余的DDR的访问，都会影响系统的整体性能。

在ss模式下，我还发现一个问题。我resizer输出720P的YUV420，再进行h264的编码保存成文件。

这个文件在PC上用暴风影音5可以直接播放，但是画面的运动部分有水波纹。

而且，我在dm368的板子上，运行dmai_2_20_00_15\packages\ti\sdo\dmai\apps\video_decode_io2 ，在板子上把pp5.264解压成YUV420P的pp5.yuv，然后在PC上播放这个解压后的yuv文件仍然有这个现象。

有人说可能跟解码器的deinterleave 反交错有关，可是我没有看到设置相关参数的地方。

请大家帮忙看看，ss模式下的这个问题，如何解决？

是resizer转换出来的yuv420数据有问题？

还是h264的编码或者解码有问题？

谢谢！

耗时可能会是这个原因：

"ipipeif_hw_setup（）函数中，

switch (params->source) {

            case SDRAM_YUV:

少了对utemp 的初始化，加如下代码：utemp = 0;"

你需要输出三路视频，肯定得使用continous模式，否则带宽必须不够的。

至于第三路，最简单的办法是使用DMA等比缩放，不知道你的分辨率可满足等比要求。

关于图像有水波纹的问题，我又做了些实验。

同样在ss模式下，video_loopback_resize 有水波纹，

而dvsdk_dm368_4_02_00_06\psp\linux-driver-examples-psp03.01.01.38\imp-prev-rsz\dm365\capture_prev_rsz_ss_raw_yuv.c 运行结果是正确的。

还要继续查找原因。

可以dump寄存器看看.

程序并没有出错，只是画面不对，我现在已经放弃ss模式了。

我修改了dmai代码，在连续模式下，resizer输出2路，然后进行2路编码，至于第3路，现在还没有什么好办法，我想试下软件等比缩放看看效果如何。