API变动说明

Version 3.0

1. 35x 相对于33x 的主要变动

1.1. VIF修改

VIF 模块创建task是以Device为单位，一个Device只能处理一种信号，所以需要引入group的概念。一个group 对应一个sensorpad，而一个sensorpad可以接收多种信号。以BT656为例，一个SensorPad可能会有多种信号，这时以Group对应一个Sensor Pad，Group包含的Device分别处理不同的信号。

1.2. SCL 及ISP修改

VPE拆分为ISP SCL，divp 删除。

1.3. DSIP修改

目的是方便disp device0 数据拿出来做零通道编码。

1.4. GFX/VENC/VDEC修改

GFX/VENC/VDEC添加DeviceID，SYS/RGN 添加SocID。

2. VIF

2.1. VIF框图对比

主要差异:

  1. 新增Group概念，一个Sensor pad中有可能会混合多种信号， 所以一个 Sensor pad 需要一个Group来对应接收

  2. 一个Group包含4个Device，且对应关系固定，Device处理单独一种信号

  3. 总共16个Device，最多可以使用8个，其中2个Device 0 和Device4可以设定Realtime

  4. 每个Device只有一个Chn ID0 用于MI_SYS bind后端

  5. MIPI 4Sensor Dev使用如下

    linear mode: dev0/dev4/dev8/dev12,

    hdr frame mode: dev0/1, dev⅘, dev8/9, dev12/13

  6. BT656 接口2个Sensor分别用到：sensor pad0/2

  7. Sensor Pad 和VIF Group ， Device和PlaneId 有默认的对应关系

    SensorPad0-Group0-Device0-3

    SensorPad2-Group1-Device4-7

    SensorPad1-Group2-Device8-11

    SensorPad3-Group3-Device12-15

    如果需要改变这个关系， 可以通过MI_VIF_CreateDevGroupExt

    设置Group 接收对应Sensor Pad信号， Device 接收对应Plane信号。

注意：35X系列芯片不支持改Group 和sensor pad的对应关系。

2.2. VIF流程对比

  1. 33x是在call 第一个Vif Api时创建；35x新增CreateDevGroup，根据Group主动创建Dev。

  2. 33x设置Chn参数，35x无Chn参数，直接设置GroupDev下Port属性

  3. 35x可以使用User Sensor，通过接口Cus_xxx获取Pad以及Plane Info

  4. 33x WorkMode用于表明VIF-VPE连接模式。35x中只用来表示Group中有几路信号。VIF-VPE 连接模式由bind信息自动推导。35x 具体的api 的使用参考MI VIF API。

3. ISP

3.1. ISP框图对比

  1. 33x MI_VPE 包含ISP LDC 可以把SCL也包进去, 35x将MI_VPE拆分为MI_ISP、MI_SCL，不再可以将LDC放在MI_VPE内部，需要主动在MI_ISP-MI_SCL之间bind。MI_ISP MI_SCL也需要主动bind;

  2. 33x ISP有多种组合输出情景：

    情景1：ISP-SCL realtime

    情景2：ISP buffer写出，

    情景3：ISP- LDC buffer写出

    情景4：ISP IR buffer写出

    35x 移除各组合后分为三种：

    情景1：ISP-SCL realtime

    情景2：ISP YUV buffer写出

    情景3：ISP IR buffer写出;

3.2. ISP流程对比

  1. 33x是在调用 第一个VPE Api时创建Device；35x需主动CreateDevice;

  2. 33x通过MI_VPE_EnableInputPort设定不同的Pass，35x不需要设定，由上层bind不同模块串接PipeLine;

  3. 33x可以包含LDC， 35x不再包含。MI_LDC为独立模块，需要手动bind;

  4. 35x不再保留MI_VPE_SetChannelAttr 函数;

  5. 35X ISP跟前级bind 时，走framemode的时候，可以通过MI_ISP_SetInputPortCrop在输入端做Crop;

  6. 35x MI_ISP作为独立模块，串PipeLine时需要进行bind;

4. SCL新增

4.1. SCL框图对比

差异：

  • 33x

    VPE通过Input Port确认SCL的输入源

    Input port0:ISP-SCL Realtime

    Input port1:Scl 从Dram读取

    Input port2:MI_VIF YUV Realtime

  • 35x

    MI_SCL按照输入源划分Device

    Device0: ISP Output Port0 Realtime连接，scl 的dev0 只能跟前级bind，并且只能走realtime。

    Device1: Scl dev1 从Dram读取，SCL dev1 只能跟前级走frame mode；跟 MI_Jpeg bind 可以RealTime连接。

    Device2: 只支持和MI_VIF YUV Realtime 连接

    Device3: 只支持Scl从Dram读取，只支持HWSCL5，只有 HWSCL5 能注册进Dev3，支持Rotation

35x注意事项：

  1. 相同HWSclID不可以跨Device使用，即如果CreateDevcie指定使用了SCL2和SCL3 则其他Devcie不可再使用；

  2. Output portid按照MI_SCL_CreateDevice 时设置u32NeedUseHWOutPortMask从低位到高位依次和HWSCLID 映射

    EX:stCreateDevAttr.u32NeedUseHWOutPortMask = E_MI_SCL_HWSCL2| E_MI_SCL_HWSCL3; 则port0->HWSCL2; port1->HWSCL3；

  3. Output port和后端realtime/ring/hw_autosync 绑定时，后端仅支持和一个Output port id 连接；

  4. 有MI_VDEC使用场景时Device3会被MI_VDEC创建占用，其他Device不能再使用HWSCL5；

4.2. SCL流程

35x对比差异如下

  1. 33x SCL无Device概念，35x需要主动创建Device;

  2. 33x通过设置ChnPortMode来区分SCL的输入源，35x不再需要，Device代表不同输入源;

  3. 33x MI_VPE_SetPortMode设定VPE Output port属性, 35x MI_SCL_SetOutputPortParam设定SCL Output port属性;

  4. 35x当输入源是Dram时 SCL可以通过MI_SCL_SetInputPortCrop接口，在输入端做crop;

  5. 35x MI_SCL作为独立模块，串PipeLine时需要进行bind;

5. DIVP 取消

  1. 取消DIVP模块

    33x 上DIVP 就是一个独占的SCL，支持Crop, Rotation 等功能；

  2. 35x Stretch buf 功能通过调用mi_scl 来实现；

    接口：

    MI_S32 MI_SCL_StretchBuf(MI_SCL_DirectBuf_t *pstSrcBuf, MI_SYS_WindowRect_t *pstSrcCrop,

    MI_SCL_DirectBuf_t *pstDstBuf, MI_SCL_FilterType_e eFilterType)

    注意事项：

    1. 该API使用Device3，使用前需要创建Device3；

    2. 该API是阻塞的，只有该帧数据做完才会结束。

  3. 其他（参考API模块介绍）

    使用范例可参考Demo:sdk\verify\mi_demo\source\vpe\ST_TestStritchBuff

6. RGN

  1. 接口修改

    所有接口添加形参：

    MI_S32 MI_RGN_Xxx(MI_U16 u16SocId, XXX, …);

  2. 删除枚举

    typedef enum
{
    E_MI_RGN_MODID_VPE = 0,
    E_MI_RGN_MODID_DIVP,
    E_MI_RGN_MODID_LDC,
    E_MI_RGN_MODID_MAX
}MI_RGN_ModId_e;

  3. 结构体修改

    33x 结构体

    typedef struct MI_RGN_ChnPort_s
    {
        MI_RGN_ModId_e eModId;
        MI_S32 s32DevId;
        MI_S32 s32ChnId;
        MI_S32 s32OutputPortId;
    }MI_RGN_ChnPort_t;

    35x 结构体

    typedef struct MI_RGN_ChnPort_s
{
    MI_ModuleId_e eModId;
    MI_S32 s32DevId;
    MI_S32 s32ChnId;
    MI_S32 s32PortId;
}MI_RGN_ChnPort_t;

7. VENC

  1. 删除api

    MI_VENC_GetChnDevid 
MI_VENC_SetModParam 
MI_VENC_GetModParam

  2. 改动API

    MI_VENC_InitDev ->MI_VENC_CreateDev
MI_VENC_DeInitDev-> MI_VENC_DestroyDev

MI_VENC_CreateChn 
…….
MI_VENC_GetIntraRefresh

    以上接口加上device id 的形参MI_VENC_DEV VeDev

  3. 增加device id define

    MI_VENC_DEV_ID_H264_H265_0
MI_VENC_DEV_ID_H264_H265_1
MI_VENC_DEV_ID_JPEG_0
MI_VENC_DEV_ID_JPEG_1

    新增的 dev_id提供给用户调用api 时使用。33x系列是要用户调用MI_VENC_GetChnDevid api 获取编码器类型。

8. SYS

  1. 接口修改

    所有接口添加形参：

    MI_S32 MI_SYS_Xxx(MI_U16 u16SocId, XXX, …);