Setting cropping/clipping for video capture

Hi tamo2,

This is the sample code to set cropping with capture. 

{
     Vps_CaptVipCropParams vipCropPrms;
    Int status;
    vipCropPrms.channelNum = 0u;
    vipCropPrms.vipCropCfg.cropStartX = 0u;
   vipCropPrms.vipCropCfg.cropStartY = 0u;
   vipCropPrms.vipCropCfg.cropWidth = width;
   vipCropPrms.vipCropCfg.cropHeight = height;

/* Enable VIP trimmer in discrete sync mode */
if ((videoCaptureMode ==
VPS_CAPT_VIDEO_CAPTURE_MODE_SINGLE_CH_NON_MUX_DISCRETE_SYNC_ACTVID_VBLK) ||
(videoCaptureMode ==
VPS_CAPT_VIDEO_CAPTURE_MODE_SINGLE_CH_NON_MUX_DISCRETE_SYNC_ACTVID_VSYNC))
{
    vipCropPrms.vipCropEnable = TRUE;
}
else
{
    vipCropPrms.vipCropEnable = FALSE;
}
status = FVID2_control(
            pVFCCComPvt->fvidHandle[handleId],
           IOCTL_VPS_CAPT_SET_VIP_CROP_CFG,
          &vipCropPrms, NULL);

}

This code is available in omx_vfcc_drvif.c if you have access to overlay.

Ram

Hi Ramprasad,

Thanks for the info.

Unfortunately, omx_vfcc_drvif.c is not included in EZSDK 5_05_02_00. 

The closest we have is, fvid2.c / vps_fvid2_control(), but looking at functions, such as, capture_one_cb_per_frm, that use vps_fvid2_control(), I imagine that IOCTL_VPS_CAPT_SET_VIP_CROP_CFG needs to be implemented somewhere else already.

I have searched IOCTL_VPS_CAPT_SET_VIP_CROP_CFG in the entire EZSDK source tree but it is not used.

So, what can we do?  Is there any way to get access to omx_vfcc_drvif.c and associated files?

Thanks,
tamo2 

Hi tamo2,

Are you using OMX ILClient or V4L2 application?

If you are using OMX currently there seems to be  no index to set cropping using SetParameter or SetConfig. You may have to get overlay code to forcibly set this here.

In V4L2 also, this IOCTL is not added in capture_control of vpss.ko.

Thanks

Ram

Hi Ram,

We use V4L2 for capturing video.  

> You may have to get overlay code to forcibly set this here.

I don't know what you mean by "overlay code".  Does it have an official name?  Is it something we can get under NDA?

For the time being, we will capture bigger image and crop it by ourselves by adjusting pointer and stride.  That works but not ideal -- it must be using quite a bit of bus bandwidth because we have to capture much bigger image (300 pixels horizontally x 26 lines).

Thanks,
tamo2 

Hi,

> You may have to get overlay code to forcibly set this here.

We are still looking for the "overlay code".  Can TI tell us how to get one?

Thanks,
tamo2 

Hi tamo2,

You need to contact your local TI FAE for overlay code.

Thanks

Ram

Hi Tamo,

By overlay code, it is the source code package for the HDVPSS firmware binaries that you are using. The HDVPSS firmware is running on the M3 core with an RTOS inside it. 

Can you explain what exactly is your use case? What is the input and output video resolution? What is the real issue with the video that you are seeing? Can you capture one image and attach?

Hi, Renjith 

We have already been contacting TI offline, but here is what it is:

We are capturing from a HD 720p camera using 16 bit mode.

The effective image size is 1280x720 but the camera's active pixel starts 300 pixel clocks after Hsync and 25 H lines after Vsync, so we have to capture the image as 1580x745 without the HDVPSS cropping support.

As I said, we can capture the image with blank pixels on the right and the bottom.  We "crop" the image by manipulating the pointer and stride (so it doesn't take time), and the image looks good.

The problem for us is, the bandwidth used for the capture.  1580x745 16bit/pixel image is about 0.5MBytes larger than 1280x720. We would like to eliminate the unnecessary transfer of blank pixels.

We run lots of algorithms on both ARM and DSP with multiple DMAs running at the same time, so we want to eliminate unnecessary data transfers as much as possible. 

Thanks,
tamo2 

Hi Tamo,

Are you using VIN port WE line (write enable). If the sensor is configured properly the active data should start only at the WE signal. If the WE is toggling at 0 and after 1279, then the capture path should only capture 1280 pixels. And WE will not be active during H/V blanking. So it should result only in 1280x720 pixels if sensor is configured properly.

Also 0.5MB/sec data rate is nothing for DM8148 as it can handle bandwidths theoretically up to 6.4GB/sec. Practically if timings are right you should be getting 5GB/sec DDR bandwidth. 

What is your bandwidth requirements?

Hi Renjith,

Renjith Thomas said:

Are you using VIN port WE line (write enable). If the sensor is configured properly the active data should start only at the WE signal. If the WE is toggling at 0 and after 1279, then the capture path should only capture 1280 pixels

No, I din't know that.  The camera doesn't generate WE signal and we don't use FPGA or anything, so we cannot do that anyway, but it is good to know.

Renjith Thomas said:

Also 0.5MB/sec data rate is nothing for DM8148 as it can handle bandwidths theoretically up to 6.4GB/sec. Practically if timings are right you should be getting 5GB/sec DDR bandwidth

It is 0.5MB per frame, so it is x 60 (and x2 camera), but still smaller than the max bandwidth. We are not reaching the max bandwidth.  It is just better not to do unnecessary things.

Since we have a workaround, this is not a high priority issue, but thanks for the useful information.
tamo2 

Hi Tamo,

Having a sensor without a WE is very unlikely. They call it with different names (OE/DE/WE) etc. May be you can cross-check.

Hi Renjith,

The camera is Sony630. The camera itself doesn't have WE and it is up to the receiver circuit.

What is the receiver circuit for? Is it a TV decoder? If so what is the chip name?