Hi,
I'm working with the IPNC DM8127 version 3.0.0.5.
I've conducted the following test ( changed the Capture-Display usecase ):
- Links Chain: [CameraLink]----720x480@30--->[NullLink]
- CameraLink configuration:
cameraPrm.captureMode = CAMERA_LINK_CAPMODE_ISIF;
cameraPrm.outQueParams[0].nextLink = myNullId;
cameraPrm.numAudioChannels = 0;
cameraPrm.numVipInst = 1;
cameraPrm.tilerEnable = FALSE;
cameraPrm.vsEnable = 0;
pCameraInstPrm = &cameraPrm.vipInst[0];
pCameraInstPrm->vipInstId = SYSTEM_CAMERA_INST_VP_CSI2;
pCameraInstPrm->videoDecoderId = MultiCh_getSensorId(gUI_mcfw_config.sensorId);
pCameraInstPrm->inDataFormat = SYSTEM_DF_YUV420SP_VU;
pCameraInstPrm->sensorOutWidth = 1920;
pCameraInstPrm->sensorOutHeight = 1080;
pCameraInstPrm->standard = SYSTEM_STD_1080P_30;
pCameraInstPrm->numOutput = 1;
/* First stream */
pCameraOutPrm = &pCameraInstPrm->outParams[0];
pCameraOutPrm->dataFormat = SYSTEM_DF_YUV420SP_VU;
pCameraOutPrm->scEnable = FALSE;
pCameraOutPrm->scOutWidth = 720;
pCameraOutPrm->scOutHeight = 480;
pCameraOutPrm->outQueId = 0;
pCameraOutPrm->standard = SYSTEM_STD_NTSC;
/* Second stream */
// pCameraOutPrm = &pCameraInstPrm->outParams[1];
// pCameraOutPrm->dataFormat = SYSTEM_DF_YUV420SP_VU;
// pCameraOutPrm->scEnable = FALSE;
// pCameraOutPrm->scOutWidth = 720;
// pCameraOutPrm->scOutHeight = 480;
// pCameraOutPrm->standard = SYSTEM_STD_PAL;
// pCameraOutPrm->outQueId = 1;
/* 2A config */
cameraPrm.t2aConfig.n2A_vendor = gUI_mcfw_config.n2A_vendor;
cameraPrm.t2aConfig.n2A_mode = gUI_mcfw_config.n2A_mode;
- The sensor Frame Valid (vsync) pin was connected to oscilloscope channel 1.
- In cameraLink_drv.c: CameraLink_drvCallback(), I've added code to toggle GPIO pin and connected that to oscilloscope channel 2.
- I've ran the system and set the oscilloscope to stop on the first few signals.
- The Results:
It seems that the capture callback does not called only after several sensor frames (6).
Does the sensor frames are dropped/ignored in the capture driver/hardware or queued?
I need to understand what is the exact behavior here.
If the frames are queued it means that the capture introduce a latency into the system - that is unacceptable due to my system requirements to very low latency.
If the frames are lost/dropped/ignored etc.. at start, but keep synced from now on, maybe I can workaround this.
Any thought on that?
Thanks,
Tal.
