雄迈3535板子，2片256M内存MMZ设置，折腾的我不轻

本帖最后由 ngswfx 于 2016-5-19 03:15 编辑

雄迈的这个3535板子，2片256M内存。

最开始，我以为3535和3531类似，既然是2片DDR,应该，分片，MMZ配置中，一个是默认NULL ，另外一个名字是DDR1

于是在load3535.sh中配置MMZ，让DDR1的开始值为0xC0000000 ，因为从0x80000000到0xC0000000 正好是1G内存，这样3535就最大支持2G了，好像是对的，启动中，执行到MMZ内存部分，也没发现什么异常，可怎么修改程序的HI_MPI_SYS_SetMemConf，

只要将名字改为ddr1，程序就崩溃，后来考虑这个板子是不是仅仅支持最大1G，于是修改ddr1从0xA0000000，还是不行，再次测试，直接搞到0x90000000,都这样了，内存就连续了。最后想想，干脆别分片了。

直接0x84000000 后面448M内存，程序竟然正常了。 已经使用了237兆内存了，加上系统的64M，已经超过了第一片DDR的256,这意味着，已经正常了。

////////////////////////////不确切知道这个板子DDR到底怎么连接的，不管了，反正这么设置，正常了。

再看文档“Hi3535与Hi3531开发包差异说明”中，有一句话让人郁闷呀:funk: ：

3535:
DDR 接口 1 个 32bit DDR3 SDRAM 最大容量支持 2GB
3531:
接口 2 个 32bit DDR2/3 SDRAM 接口 每个接口最大容量支持 1GB

看来这就是原因了，3535只有一个DDR接口，:lol 。没看文档，累死个人呀。




还有那个内存池分配，由于demo代码和3520D有些差异，需要重新摸索，尤其这个stModVbConf.astCommPool[0].u32BlkCnt，很费解，我是16路D1解码，不做其他事情，V0 HD0输出而已，这个值按照我的理解应该是16就可以了，怎么弄都不行，

只能解几路，其他的通道，发送流HI_MPI_VDEC_SendStream失败，设置成u32BlkCnt=64，16路解码就正常了，费解呀。难道是VPSS那几个处理过程（Crop NR DIE SCALE 等等），一个过程用一个？ 可是我全都配置的是HI_FALSE呀。（也不排除这种可能，内部的确会缩放合成会折腾好几次）
//////////////////////////////目前还有一个地方没搞懂，如果设置成u32BlkCnt=64，第一次连接16个D1正常，占用内存约130M左右，如果断开所有图像，再次连接，有些又失败了。暂没找到原因，估计有些东西没释放掉，临时做法，是把u32BlkCnt=80,这里想到网站上曾经不少人说3535解码多路图像卡(当然也可能是网络传输方面的问题），呵呵，如果这个内存池子分配的不够，各个通道在抢内存，图像的确会卡:lol，这个也能解释的通 。


////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
代码VB_PIC_BLK_SIZE(stSize.u32Width, stSize.u32Height, PT_H264, PicSize);   里面
把   size = ( (u32AlignWidth * u32AlignHeight + u32HeadSize) * 3) >> 1;\
改为 size = ( (u32AlignWidth * u32AlignHeight + u32HeadSize) * 3) >> 2;\

能节省一半内存。这个倒是符合文档描述。最小缓冲：w*h*3/4
////////////////////////////////////////////////////////////////////////////////////////////后来经过大侠指点，这里不能动，必须是w*h*3/2(估计是YUV420)，之所以我测试没发现问题，是因为我的W=1920 H-1080,测试的图像是D1的，所以一切正常，但如果导入1080P图像，这里会引起失败。


//////////////////////////demo中的这句，估计也浪费不少内存，为了支持旋转，如果1920*1080 ,VPSS缓冲按照1920*1920计算的，浪费了不少内存。
stRotateSize.u32Width = stRotateSize.u32Height = MAX2(stSize.u32Width, stSize.u32Height);
///////////////////////////////
stVpssGrpAttr.u32MaxW   =stSize.u32Width;// ALIGN_UP(stRotateSize.u32Width,  16);
stVpssGrpAttr.u32MaxH   =stSize.u32Height;// ALIGN_UP(stRotateSize.u32Height, 16);



////////////////////////////////////////2016_5_18  有了高手的解惑，又查看了文档，在 MPI2.0 里面HI_MPI_VDEC_CreateChn有相关描述。更清楚了些。
创建解码通道之前要先创建专属于 VDEC 的模块 VB 池,且要保证 VB 块的大小
和个数满足当前解码通道所需图像 Buffer 的大小和个数。H264 和 JPEG 解码每个
解码通道所需 VB 个数至少为参考帧+显示帧+1;MPEG4 解码每个解码通道所需
VB 个数至少为参考帧+显示帧+2。不同协议解码所需的图像 VB 块大小不同,具
体计算方法可参见下面的 VB_PIC_BLK_SIZE 定义。
z 当前创建的 H.264 解码通道如果设置支持 B 帧解码,则还需要为其分配输出每一
帧 Pmv 信息的 VB 块,该 VB 块的大小比图像 VB 块小很多,所需个数与图像 VB
个数保持一致,具体大小计算可参见下面的 VB_PMV_BLK_SIZE 定义。
z 如果 H.264 解码不需要解码 B 帧,则创建通道时可设置此通道不支持 B 帧解码,
此种情况不输出 Pmv 信息,可以不用创建 Pmv VB 池,节省 MMZ 内存。
z 如果解码帧存分配方式使用的是解码私有 VB 池,则不需要创建解码模块 VB
池。
z 如果设置了旋转,则两种帧存分配方式都需要为每个解码通道多分 3 块 VB。

//////////////////////////////////////2016_5_19 SAMPLE_COMM_VDEC_InitModCommVb用起来真不方便，这个公共缓冲池子用起来真不方便，最起码我的应用环境是这样
MPI2.0有一句：
VDEC 模块公共池仅在解码帧存分配方式使用模块公共 VB 池时才需要创建,即
VDEC 的模块参数 VBSource 配置为 0 时。如果 VDEC 的模块参数 VBSource 配置
为 1,则不需要创建 VDEC 模块公共 VB 池。
//如果使用公共缓冲池，在KO加载驱动时，VBSource=0，而且SDK默认就是这么用的，我的应用环境是16路D1解码，偶尔会某个通道解高清。
//如果配置这个公共缓冲池方式的话，由于是静态变量，系统初始化的时候就启动，配置小了的话，高清解不了，配置大了，内存又不够，真是左右为难。
//幸亏MPI可以关闭，不使用这个公共缓冲池，改由内部自动分配，哎，天下太平了，内存占用区别巨大，目前16路D1解码占用约100M，如果再让其中一个通道解400万像素高清
，再增加约30M，总共约130M，这种内存使用就比较完美了，如果用公共池自己分配的方式，完成这些任务，如果程序启动就分配到位的话，1G的内存配置就必须满足了，因为16路高清（2480*1536）解码VB就估计占用了400多M了。


////////////////////////////////到这里，基本和3520D差不多内存占用了，比较完美。结贴。