媒體處理參考設計說明

非經(jīng)本公司，任何單位和個人不得擅自摘抄、本文檔內(nèi)容的部分或全部，并不得以任何形式。 您的產(chǎn)品、服務或特性等應受海思公司商業(yè)合同和條款的約束，本文檔中描述的全部或部分產(chǎn)

數(shù)據(jù)容量（如RAM容0b000、X1例如：00X表示000或001；1XX表示

前 概 概 概 概 概 概 概 概 其 圖1-1NDK上下 圖2-2Hi3559V100單Sensor單通路設計 圖2-3Hi3559V100單Sensor單通路設計 圖2-4Hi3559V100單Sensor雙通路設計 圖2-5Hi3559V100單Sensor雙通路設計 圖2-6Hi3559V100單Sensor雙快速通路設計 圖2-7Hi3559V100單Sensor雙快速通路設計 圖2-8Hi3559V100雙Sensor雙雙設 圖2-9Hi3559V100雙Sensor雙雙設 圖2-10單Sensor單路時序 圖2-11單Sensor雙時序 圖2-12單Sensor雙快速時序 圖2-13雙Sensor時序 圖2-14雙Sensor時序 圖2-16拍照后處理設計流 圖2-18數(shù)據(jù)流接口時序 NDKSDK(MPIFastInitMAPICPU異構。的軟件層。NDK在LiteOSLinux系統(tǒng)上都能對接上層APP開發(fā)。 Linux系統(tǒng)上，具有通用性好，成熟穩(wěn)定等特性，為了客戶方便沿用之前的業(yè)務開發(fā)習慣，將其他通用業(yè)務APP布局在Linux系統(tǒng)上。也即NDK在 務APP。 LiteOS系統(tǒng)上，故將NDKLiteOS上的軟件部分稱為MediaServer，linux系統(tǒng)的軟件部分稱為Media MediaServer與Media 通過HiSysLink實現(xiàn)消息通信與大塊數(shù)據(jù)通信，具體通信機制見2.9章節(jié)。在LiteOS系統(tǒng)上，MediaServer通過調(diào)用MPI接口實現(xiàn)功能的整合與抽象；在Linux端，通過HiSysLink系統(tǒng)建立消息及數(shù)據(jù)通信，實現(xiàn)Media │ ││├──av││└──│ ││├──││├──││├──││├──││├──││├──││├──││├──││├──││├──││└──│ ├── ├── ├──││││ │││││││││││ │ │ │ │└── │ ││├──│││└──││├──││└──│ ├──│ └──│ ├── ├── └── ├── │└── └── │├──│├──│├──│├──│├──│└──└── └──

接口頭文件命名規(guī)則：hi_mapi_xxx.hxxx為modulename。比如音頻輸入的音頻輸入的數(shù)據(jù)結構頭文件命名為hi_mapi_acap_define.h接口命名規(guī)則：HI_MAPI_XXX_YYY(param1,param2,param3,，一般將輸入?yún)?shù)放前面，輸入?yún)?shù)放后面。比如音頻輸入音量設置接口為HI_S32HI_MAPI_ACap_SetVolume(HI_HANDLEACapHdl,HI_MPP_AUDIO_GAIN_S*LiteOS端的代碼放在\ndk\mapi\code\mediaserver

LinuxHiSysLinkmedia的接口調(diào)用與數(shù)據(jù)通信。通信方式有兩2.9章節(jié)。

Capture，簡稱VCAP）模塊實現(xiàn)的功能：通過MIPIRx(含MIPI接口、LVDS接口和HISPI接口)接收數(shù)據(jù)，將前端輸入的原始數(shù)據(jù)送入到內(nèi)部的圖像信號處理單元(ISP)進行處理，并最終輸出YUV數(shù)據(jù)給后處理模塊( 稱VPROC)。VCap模塊封裝了Sensor、VI、ISP這幾個模塊，將前端 用戶在對接不同Sensor時，只需要改動較少的配置就能實現(xiàn) 1.g_ssorCtxMsgcommand:厖SDK厖為sensor_cfgdis_cfgmapi_vcap_.c文件為VCap的MAPI msg_server.c在收 msg_vcap.cVCapServerMAPImapi_vcap.c文件為VCapMAPIServerSDKMPI接口完成?g_s Sensor的相關參數(shù)。?g_stVcapsCtx[VCAP_NUM]，該全局變量用于保存用戶通過接口輸入的?sensor_cfgSensor的相關參數(shù)，該參數(shù)的配Configs/sensor/Hi3559/panasonic_mn34120/sensor_interface_cfg_params.c中，包括對應Sensor的所有模式列表，以及每個模式下的時序配置。?dis_cfg，該全局變量用于保存Dis的相關參數(shù)，該參數(shù)的配置實際來源于Configs/dis/Hi3559/panasonic_mn34120/dis_cfg_params.c，包括不同的DIS算法?g_pstVcapInnerCfgVCap模塊內(nèi)部結構需要的參數(shù)，這此，寫死在g_pstVcapInnerCfg全局變量中，具體的賦值是在arch/hi3559/vcap/adpt_vcap_inner_config.c和arch/hi3559/vcap_double/adpt_vcap_inner_config.c文件中，由于單Sensor和雙Sensor的配置有差異，所以，單雙Sensor分別配置在不同的文件中，用戶在 下有gyro和sensor兩個 ? ? 《Sensor調(diào)試指南.docDataflow

Dataflow

圖2-2和圖2-3為單Sensor單通路設計的兩種情況。由于Hi3559V100中MIPIRx0接收圖像。圖2-3中，采用VCap1進行，在該通路中，VCap1具有BayerScl功能，MIPI1倍、1/2倍、1/3倍縮放，達到在較低功耗下能得到好該設計中，用戶可根據(jù)應用場景及實際性能需求靈活選擇對應的VCap做，只需要將VCap的類型選為 ControlflowDataflow VCap0.enVCapType= Dataflow

VCap0enVCapType=

VIVI

VIDev

VIVIVIVIDev

VCap1.enVCapType= Photo圖2-4和圖2-5為單Sensor雙 作為通路的VI設備自產(chǎn)生時序，自產(chǎn)生的時序的分辨率與通路寫出幀的分辨率一致。因此，在圖2-5中，當Vcap1作為通道時，不能進行BayerScl ControlflowDataflow VCap0.enVCapType=ControlflowDataflowVCap1.enVCapType=圖2-6和圖2-7為單Sensor雙 通路的VI設備與MIPIRx0綁定，并接受MIPI輸出的圖像，當停止時， 通路的VI設備解除與MIPIRx0的綁定(即綁定到無效MIPIRx1上)。當MIPIRx0與兩個VI設備同時都綁定之后，兩個VI設備均能到當模式設置為QUCIK模式時，要獲取到普通 幀，需要通過從VI通道中獲取YUV數(shù)據(jù)，并標記幀，再將幀送給VPSS做 不實際控制Sensor，因此需 ISP去控制Sensor的 均得到長幀， Dataflow VIVIVIVIDev

VIVIDev

雙路通路設計中，MIPIRx0與VI設備0綁定，MIPIRx1與VI設備1綁定，由于受MIPI能力限制，MIPIRx0最多支持12lane，MIPIRx1最多支持4lane，因此對Sensor及時序的選定有一定的要求。雙路通路設計中，ISP0控制Sensor0，ISP1控制Sensor1對于Vcap1而言，如果有進行BayerSclBayerSclDataflow VIVIVIVIDev

Photo

設計中，在不進行的情況下會有實時數(shù)據(jù)流出，在用戶觸發(fā)后，設置ISP的拼接屬性保證。2-22-10所示，包括OSD和Dis

為8M@30fps

給打時間

HI

HI_MAPIVCapOSD_SetAttr

以圖2-4為例的時序如圖2-11所示。值得注意的是，通路的實際幀率并不由的幀率為60fps，但是屬性中的幀率為5fps，最終通路的幀率為5fps。

為8M@60fps

為 模式

啟動啟動

為 模式

啟動啟動設

在圖2-12的時序圖中，在設置屬性和觸發(fā)兩個接口的調(diào)用時序中分為黑色和MAPI_Vcap_InitHI_SUCCESS (08M@30fps)為 模式(0,(8M@30fps啟動啟動為模HI_MAPI_VCap_SetAttr 啟動啟動 綁 通MSG_CMD_VCAP_B設 (0,QuickMode/PRO_ONL (0,QuickMode/PROONLINE)HI_MAPIVCapTrigger/得到1長建立所消耗的時間造成時序不一致，需要調(diào)用HI_MAPI_Sensor_SetMode接口將Sensor首先設置為Standby模式，在將所有的業(yè)務通路都建立之后，再調(diào)用HI_MAPI_Sensor_SetMode接口將Sensor設置為普通模式。另外，為了能保證的圖像風格一致，需要分別設置兩個ISP的模式為拼接(STITCH)模式。

HI

HI_MAPI_Sensor

HI_MAPIVCapIsp_Start

HI_MAPIVCapStart

)

HI_MAPI_SensorSetMode(1,STANDBY)

)

HI_MAPI_SensorSeMode(0,NORMAL) 雙Sensor時以圖2-8為例的雙Sensor時序如圖2-14所示。雙Sensor中觸發(fā) 單Sensor中的不一樣，單Sensor中調(diào)用HI_MAPI_VCap_Trigger觸發(fā) 中，為了保證能同時得到兩條通路中的數(shù)據(jù)，需調(diào)用HI_MAPI_VCap_SyncTrigger接

HI_MAPI_Sys_Init,

MSG_CMD_MEDIA_SYS_

設置Sensor0

(09M@15fps)

的Standby

設置VCap0屬 為9M@15fps，模式

設置Isp為拼

(0,(9M@15fps (0,HI_MPP_VCAPCMD啟動啟動設置Sensor1

HI_MAPIVCapIsp_StartHI_MAPIVCapStart(19M@15fps)的Standby

設置VCap1

為9M@15fps，模式

(0,(9M@15fpsSnap)) (1,HI_MPP_VCAPCMD啟動啟動 設置Vcap0的屬性

為Standby模式，的專業(yè)模式，120s (0,PROT

(0,PROTUNE120s 設置Sensor0

(1,PROTUNE,120s)

(1,PROTUNE120s 的Normal模

設置Sensor1模

的Normal模

HI_MAPI_Sensor_SetMode(1,NORMAL)至此，兩個同步觸發(fā)同時生

HI_MAPIVCapSyncTrigger

DumpRaw2-15所示。圖中展示了Raw數(shù)據(jù)通過端返回給產(chǎn)品時刻調(diào)用HI_MAPI_VCap_EnableDumpRawHI_MAPI_VCap_DumpRaw兩個接口即

VB為為啟動啟動

(08M@30fps)(0,(8M@30fps

使能

至此，有YUVDumpRaw

VCap的初始化接口為內(nèi)部接口MAPI_VCap_Init，去初始化接口為內(nèi)部接口MAPI_VCap_DeInit，均被mapi_sys.c中的HI_MAPI_Media_Init接口調(diào)用。這兩個接口主要是用來初始化和清除全局資源，主要包括g_s ?MIPI?保存當前模式到全局變量 ?通過當前VCap的模式 ?設置VI?綁定VIMIPI?設置VI?保存當前VCapg_stVcapsCtx?Sensor回調(diào)函數(shù)?如果用戶調(diào)用HI_MAPI_Sensor_SetModeSensorStandby模式，則調(diào)用回調(diào)設置Sensor的初始化序列為Standby。?配置通路的ISP與Sensor綁定?3A算法庫 ?IspFirmware?反3A算法庫?反Sensor回調(diào)函數(shù)?Isp?使能VI?使能VI?保存VCap?如果使能了，則禁用?禁用VI?禁用VI?清除VCapg_stVcapsCtxVCap?設置Isp的屬性?設置VI的屬性?保存參數(shù)到全局變量g_stVcapsCtx中通道與有效MIPI0綁定。?通道與無效MIPI1綁定?禁用屬性Trigger?禁用，保證釋放上次的資源?啟用?觸發(fā)?VCAP和后端VPROC?VIYUV??將獲取的所有的幀送給VPSS??VCAP和VPROC?禁用，保證釋放上次的資源?使能?同時觸發(fā)兩通的?設置DCF?設置GPS?獲取DCF?獲取GPS

?如果OSD已經(jīng)啟動，動態(tài)設置顯示屬性并填充BMP到OSD區(qū)域上?保存當前OSD?創(chuàng)建OSD?填充BMP到OSD區(qū)域上?OSD?保存OSD?OSD?銷毀OSD?保存OSD?設置DIS?DIS?設置DIS?如果DIS算法中需要陀螺儀數(shù)據(jù)，初始化陀螺儀、啟動陀螺儀獲取數(shù)據(jù)、獲取陀螺儀數(shù)據(jù)接口給DIS算法庫。?創(chuàng)建線程啟動DIS?保存DIS?設置DIS?如果開啟了陀螺儀的相關算法，反獲取陀螺儀數(shù)據(jù)的接口、停止陀螺儀獲?退出DIS?銷毀DIS?保存DIS?設置Dump?啟用VIDump?VI?銷毀獲取Dump?禁用VIDump?Dump數(shù)據(jù)的回調(diào)?置圖像效果的接口，并不屬于通路建立所必須的接口，這類接口主要是透傳SDKHI_MPP_VCAP_CMD_E，并且在Server端(即mapi_vcap.c)添加相應的分支調(diào)用SDK相應的接口即可。用戶在使用時，可使用或Server端的接口，結構體直接通過包含SDK的結構體得到。????VPROC的定位是做YUV數(shù)據(jù)的處理，主要包含了MPIVPSS的功能，另外封裝了VPROC的HANDLEMPI層VPSS的Group號，PORTHANDLEMPIVPSSchn拍照后處理需要將VPSS輸出的幾幀數(shù)據(jù)通過HDR、LL等后處理算法合成為一幀這個流程。以三幀合成處理為例如圖2-16所示。需要注意的是VPSS和VENC在驅動層已經(jīng)綁定，VPSS如果有數(shù)據(jù)輸出會直接送給VENC編碼，還沒有做HDR/LL處理，這并不是用戶期望的結果。所以，需要在VPSSVPSSVENCVPSS有數(shù)據(jù)輸出時，通過MPI的HI_MPI_VPSS_GetChnFrame接口獲取出三幀數(shù)據(jù)，然后送給HDR/LL處理。整個處理封裝在VPROC的實現(xiàn)內(nèi)部，用戶的產(chǎn)品代碼中直接調(diào)用MAPI的代碼需要對比HDR/LL處理前后的YUV數(shù)據(jù)，這個場景下用MAPI的接口來做就比較，建議這種調(diào)試場景還是調(diào)用MPI的接口來做。VPSS4個物理通道，如果客戶需要4個以上的通道數(shù)時，可以使用擴展通道。但是由于擴展通道的概念稍微復雜，就沒有在MAPI層使用。這種情況如果需要4個以上的通道，又沒有擴展通道，只能再創(chuàng)建一個新的VRPOC，需要再做一次3DNR處理等，對功耗和內(nèi)存占用上MAPI3DNR的參數(shù)幀個數(shù)固定了，SNAP模式時，用0個參考幀；當前MAPI層并沒有開放VPSSGroup屬性的enPixFmt設置，這個值主要影響3DNR參考幀的buffer分配大小，為了最大的兼容性，MAPI層固定設為了少buffer的分配。

編碼（Encode，簡稱VENC）模塊對MPI的VENC/RC/H264/H265等模塊和HiSyslink的datafifo進行了封裝，主要實現(xiàn)了編碼碼流的獲取和跨核的傳輸，同時添加了編碼OSD信息。ProcessVEncStreamThreaddatafifo通道獲取音頻編碼后的數(shù)據(jù)信息，執(zhí)行用戶數(shù)據(jù)寫入[用 數(shù)[參數(shù)MAPI_VEnc_HI_DA VEVENC接口設計將原有MPI接口參數(shù)進行了簡化，基本的常用的功能參數(shù)，在通道初?MPI層接口HI_MPI_SYS_BindVPORT?VIMPI層接口更新RC 端打開datafifo?serverdatafifo ?serverdatafifo????參數(shù)轉換后，調(diào)用MPI層接口設置編參?RC?全部都是接口透傳，未做任何修改。僅在高級幀率控制時，回去更新RC參數(shù)。在VENC增幀時，RC的輸入幀率是增幀后的幀率，VENC不增幀時，RC的輸入幀率是VI的幀率。?全局變量中獲取設置是OSD?MPI層接口創(chuàng)建RGN?設置OSD?MPI?MPI層接口拆除OSD?MPI層接口銷毀RGNDISP模塊的HANDLEVO的DEVVoLayerID；DISPWindow的HANDLEVOchnIDDISPMAPI層的參數(shù)到MPI層，并沒有復雜的邏輯轉換，DISP模塊的接口HI_MAPI_Disp_Start實現(xiàn)中，因為要考慮兼容各種應用場景，固定調(diào)用了HI_MPI_VO_SetDispBufLen4buffer4幀的緩存buffer在場景為單畫面直通的情況下，是可以省下來的。是否滿足單畫面直通的場景條件，請參考《HiMPPIPCV3.0處理軟件開發(fā)參考》文檔中，輸出

(AudioCapture，簡稱ACAP)用于接收AudioCodec轉換之后的音頻數(shù)字信號 2-19所示，AI設備啟動trackmode設置→AI→VQE屬性設置→VQE使能。啟動2-20VQE→停止AI→停止AIndk\drv\extdrvcodec文件夾，將驅動代碼放入