Image glitches on Appro MT5 DM368

The green dots could be issues with setup/hold AC timings between the sensor and the DM365.  Could you try inverting the PCLK either on the sensor, or the processor receive side and see if that helps?  Capture this on a scope to see if you're violating the setup or hold times on the pins of the processor.

Is the tearing occurring on the decoded image on a PC (after being received over ethernet stream and decoded by the PC)?  This could be caused by two things:

• The capture buffers are not properly setup.  Some buffers could be getting overwritten with new data
• The PC decoding the stream is not keeping up properly with the stream - try a lower resolution

Hi Ivan, thanks for taking a look.

Our input (Sony FCB-EH block via LMH0031) doesn't allow the PCLK to be inverted easily, I spent ages searching for the code/defines to invert PCLK and eventually did this in CSL_vpssGetClkDiv():

prm->VPSSCLKCTL     = gCSL_drvGpioObj.sysRegs->VPSS_CLK_CTRL;
// TRY to invert PCLK here...
prm->VPSSCLKCTL |= 0x00000004;

But it didn't do anything noticeable! A bit concerning really! I'm wondering now if the VPSS is running from its own clock rather than triggering from PCLK, although that would surely fall out of lock / stop working very quickly.

The tearing is on the PC decoding the stream (in VLC), but it's a quick PC that has no problem decoding 1080p30 etc. and we've had streams running reliably previously (with no changes in the code, which is frustrating!) I'm working through trying difference encode combos to see if it's just a glitch with one of the profiles.

The capture buffers are (or should be) as per the Appro SDK, which hopefully means they are correct for the chosen capture/encode setup.

Following the experiment above, I decided VPSSCLKCTL wasn't being set correctly for PCLK input (I still can't see a sensible looking bit of code where it's all configured) but changing the above line to:

gCSL_drvGpioObj.sysRegs->VPSS_CLK_CTRL |= 0x00000007;

Resulted in this:

So at least it made a visible difference this time!

Could you check with a scope to make sure you're running at the correct frequency?

I'll let someone in the SW team comment on the configuration software.

I'll drag the scope over and see what I can see.

It would be most helpful if the software team (especially someone like Anushman who seems to be the expert) could help me out with my other thread about the correct way to go about configuring the capture path. I'm sure I'm not using the optimal config for the application.

Bob,

Are you running capture in one-shot mode or continous mode of ISS?

Can you try reducing the FPS and provide feedback if the glitches go away?

Regards

Rajat

As far as I can tell, nothing is one-shot:

ipnc_rdk/av_capture/framework/drv/usermod/src/drv_ipipe.c
620:  gDRV_ipipeObj.bscInfo.oneShotEnable   = FALSE;
713:    gDRV_ipipeObj.bscInfo.oneShotEnable = FALSE;
759:  gDRV_ipipeObj.histoInfo.oneShotEnable = FALSE;
878:  gDRV_ipipeObj.rszSetup.oneShotEnable  = FALSE;
934:    pOutConfig->oneShotEnable          = FALSE;
1028:  gDRV_ipipeObj.ipipeifDdrInConfig.oneShotEnable   = FALSE;
1105:  gDRV_ipipeObj.boxcarConfig.oneShotEnable = FALSE;
1179:  gDRV_ipipeObj.ipipeSetup.oneShotEnable              = FALSE;

Which of the various FPS's should I try reducing? I guess reducing the encode FPS with frame skipping as we cannot drop our input FPS (camera runs at 1080p30).

Well, frame-skipping down to 15fps in the encoder seems to make no difference to the tearing / juddering of the image:

I have managed to stop the tearing by more frame skipping.

In the example above, I'd edited the capture/encode profile in avServerUI.c like this, duplicating the method used for encoding 15fps from a 30fps stream for the profile AVSERVER_UI_CAPTURE_MODE_720P_VGA:

config->encodeConfig[i].frameSkipMask = 0x1AAAAAAA;
config->encodeConfig[i].frameRateBase = (config->sensorFps*1000)>>1;

After that failed, I went back and also added skipping to the captureConfig:

config->captureConfig[i].frameSkipMask   = 0x1AAAAAAA;

And that has resulted in a smooth 15fps stream.

Putting my best Sherlock Holmes hat on, I guess that means the issue is in the capture side rather than the encode side.

It would be nice if the Appro capture/encode parameters were documented as it seems to me that skipping alternate frames in both the capture AND encode tasks should result in 7.5fps ((30/2)/2)

I've returned to investigating this, altering the frame-skipping: If I set the capture config to frame-skip (config->captureConfig[i].frameSkipMask = 0x1AAAAAAA;) but leave the encode at full rate:

config->encodeConfig[i].frameRateBase = (config->sensorFps*1000);
config->encodeConfig[i].frameSkipMask = 0x3FFFFFFF;

Then it still works smoothly, the video stream runs at 30fps according to VLC.

This happens in both 1080p modes - in avServerUI.c: AVSERVER_UI_CAPTURE_MODE_1080P and AVSERVER_UI_CAPTURE_MODE_1080P_D1.