3535做动态分辨率解码 MPI2.0 禁用VDEC公共缓冲池

本帖最后由 ngswfx 于 2016-5-19 07:10 编辑

最近做3535动态解码，要求普通模式下16路D1解码，偶尔能够支持4画面或者单画面高清解码。

在3520D上，这种模式很正常，仅仅是高清部分能支持到1080P而已。移植到3535上，想做更高分辨率解码，就发现问题了。
由于SDK默认的KO装载里面，VDEC KO装载，多了个针对VDEC的公共缓冲池的概念，折腾我不轻。因为自我感觉，内存占用太大了。
见上一帖子：

[url]http://www.ebaina.com/bbs/forum.php?mod=viewthread&tid=11343&extra=page%3D1[/url]

/////////////////////////今天这篇主要着重强调，原来这个缓冲池，是可以关闭的。呵呵，发现新大陆了。:lol
使用公共缓冲池，我遇到的问题：如果程序启动，在VDEC初始化时，如果按照2480*1536去分配公共缓冲池，16路分割窗体，内存开销太大，512M内存不够用。其实MMZ内存大部分在浪费状态。
//根据我测试的情况来看，这个公共缓冲池，如果u32BlkSize设置小了，高清解不了，如果u32BlkCnt个数不够，图像解不出来（比较郁闷的就是，底层真的是按照我的配置u32BlkSize在限制，内存就摆在那里，允许闲着，都不敢超标使用:lol ）。
//而且这个参数不是针对某个通道的，针对全局的，只要你支持这么多解码通道，就必须把u32BlkCnt搞的足够大，只要你要支持大的分辨率u32BlkSize就必须大，而最后的VB内存就是2个参数乘出来的，超级大，弄不好几百兆。

最折腾的地方是，不知道怎么动态分配。
MPI2.0文档中，有一句：
pstVbConf 模块公共视频缓存池属性指针。静态属性。  
////我感觉不好弄成动态调整的了。

如果初始化阶段，按照D1方式配置，16路VDEC，运行中，如果要让某个通道解码更高分辨率，就比较麻烦了，这个公共缓冲池是个静态变量，一旦创建，如果销毁，通道解码就得重新配置了，太麻烦了，我感觉没什么好的动态切换方法。

/////////MPI2.0文档中：
注意】
z 当前公共视频缓冲池仅适用于 VDEC 模块。
z 必须先调用 HI_MPI_VB_Init 进行公共视频缓冲池初始化。
z 必须先调用 HI_MPI_VB_SetModPoolConf 配置缓存池属性,再初始化缓存池,否
则会失败。
z 可反复初始化,不返回失败。
z VDEC 模块公共池仅在解码帧存分配方式使用模块公共 VB 池时才需要创建,即
VDEC 的模块参数 VBSource 配置为 0 时。如果 VDEC 的模块参数 VBSource 配置
为 1,则不需要创建 VDEC 模块公共 VB 池。
///////////////////////////////////////////////////////////
为此，我关闭测试了一下：
//将load3535中，VDEC驱动加载修改一下：
insmod hi3535_vdec.ko VBSource=1 MiniBufMode=1
//初始化阶段，不做SAMPLE_COMM_VDEC_InitModCommVb动作。
呵呵，太明显了，程序启动，开16路D1解码，MMZ内存仅仅用了92M，开启15个D1解码，再开一个通道2480*1536解码，MMZ也就使用130M左右。
MMZ分配和以前3520D基本一致，随着通道的创建销毁，动态创建VB缓冲池，一个通道一个VB。

部分MMZ信息如下：
|-MMB: phys(0x8890F000, 0x8893FFFF), kvirt=0x  (null), flags=0x00000000, length=196KB,       name="model buf"
   |-MMB: phys(0x88940000, 0x88DBFFFF), kvirt=0x  (null), flags=0x00000000, length=4608KB,      name="vb"
   |-MMB: phys(0x88DC0000, 0x890B7FFF), kvirt=0x  (null), flags=0x00000000, length=3040KB,      name="vb"
   |-MMB: phys(0x890B8000, 0x893AFFFF), kvirt=0x  (null), flags=0x00000000, length=3040KB,      name="vb"
   |-MMB: phys(0x893B0000, 0x8942BFFF), kvirt=0x  (null), flags=0x00000000, length=496KB,       name="Vdec12_StreamBu"
   |-MMB: phys(0x8942C000, 0x89723FFF), kvirt=0x  (null), flags=0x00000000, length=3040KB,      name="vb"
   |-MMB: phys(0x89724000, 0x8979FFFF), kvirt=0x  (null), flags=0x00000000, length=496KB,       name="Vdec13_StreamBu"
   |-MMB: phys(0x897A0000, 0x89A97FFF), kvirt=0x  (null), flags=0x00000000, length=3040KB,      name="vb"
   |-MMB: phys(0x89A98000, 0x89B6FFFF), kvirt=0x  (null), flags=0x00000000, length=864KB,       name="Vdec14_Ctx"
   |-MMB: phys(0x89B70000, 0x89E67FFF), kvirt=0x  (null), flags=0x00000000, length=3040KB,      name="vb"
   |-MMB: phys(0x89E68000, 0x89F3FFFF), kvirt=0x  (null), flags=0x00000000, length=864KB,       name="Vdec15_Ctx"
   |-MMB: phys(0x89F76000, 0x8A00CFFF), kvirt=0x  (null), flags=0x00000000, length=604KB,       name="Vdec6_Scd"
   |-MMB: phys(0x8A00D000, 0x8A0A3FFF), kvirt=0x  (null), flags=0x00000000, length=604KB,       name="Vdec7_Scd"
   |-MMB: phys(0x8A0A4000, 0x8BE4DFFF), kvirt=0x  (null), flags=0x00000000, length=30376KB,     name="vb"
   |-MMB: phys(0x8BE4E000, 0x8C330FFF), kvirt=0x  (null), flags=0x00000000, length=5004KB,      name="Vdec1_StreamBuf"
   |-MMB: phys(0x8C90F000, 0x8CEECFFF), kvirt=0x  (null), flags=0x00000000, length=6008KB,      name="Vdec1_Scd"
---MMZ_USE_INFO:
total size=458752KB(448MB),used=131904KB(128MB + 832KB),remain=326848KB(319MB + 192KB),zone_number=2,block_number=133

/////////////////其中3040KB就是D1比较小的VB，最大的那个30376KB，30M的，就是2480*1536的VB。

/////////////这种动态的方法，很适合动态调整分辨率解码。应用比较完美。