How to get YUV422 image with size of 1080p using DM365 EVM board

Are you using DM365 EVM from Spectrum Digital + LI-5M02?  If so, what software are you using, the DM365 DVSDK or what came with the LI-5M02 board?  My understanding is that some of the upper level software in the DVSDK does not support 1080p, but the following wiki shows how to add support for 1080p to the DVSDK demos.

http://wiki.davincidsp.com/index.php/Adding_Display_Resolutions_to_DMAI

I am not familiar enough with LI-5M02 software to know what it supports, so you may have to go to the third party which makes this board for support on it.

Thank you for your answer.

We are using the DM365 DVSDK, the LI-5M02 provide a patch to the kernel. 

best regards

hi, Juan

Thank you for your answer again.

We tried the method in the link you give, but in our application we didn't enable the output and display at all. 

The display is disabled in our test, and only the previewer and resizer is enabled. We just save Raw Bayer image buffer or YUV buffer to files in the capture loop.

And the question is, only 480p YUV image can be saved. 

Is there something wrong?

best regards

What demo are you using?  You mention demo is SDK, maybe 480p is a limitation of the particular demo you are using.

Our DVSDK encode demo for DM365 does support up to 720p capture via component input, but does not support capture from LI sensor card; In addition, our DMAI demos support 1080i as well, but again not the LI-board support.  Therefore I am wondering if this is a demo provided by Leopard Imaging.  If so, then I am afraid you may get better help going to them.

hi, Juan

Thank you for your answer!

Now we have got 720p and 1080p YUV422 image. But is some thing wrong in the image.

The image from the sensor board is 2592x1944 raw bayer format. And now we can get two kind of 1080p YUV422 image:

1) If we set dm365 to accept 1080p bayer image, the first 1080 pixel of the 2592 pix can be got.

2) If we set dm365 to accept 2592x1944 bayer image, all the pixels in the image is processed in the ipipe(previewer), and the output is 1080p YUV( I guess  the resizer convert the  2592x1944 YUV to 1080p YUV). But as in the data sheet, only 2176 pixels can be processed, so the right part of the image is in disorder(from 1614 to 1920).

And now my question is :

How to cull or decimate the 2592x1944 raw bayer image to bayer format in size of 1080p. Is there only the CULH an CULH register can be used to resize the raw bayer image input to IPIPE? 

Best regards

within the IPIPEIF set of registers (see section 6.2 on VPFE UG), you want to enable horizontal decimation via CFG1.DECIM and set the RSZ register (not to be confused with resizer module which includes a set of registers) to your desired size.

so long as your input data comes from SDRAM, you can choose to use continous or one-shot mode.  I believe input from SDRAM is the driver default, allowing you to exercise both modes.  If the driver was configured such that data wend from ISIF to IPIPE directly without going thru SDRAM, then you can only choose continous mode; this is likely more efficient since you are saving the cost of writting to SDRAM and then reading from SDRAM (done video video DMA hardware automatically, but you still use DDR2 bandwidth).

hi, Juan

Thank you for your answer!

The working flow we want is:

1) the data is from a CMOS sensor, and DM365 working in Continues mode; convert the 2592x1944 raw bayer image to 1080p YUV image to get video stream. 

2) and when interrupt comes, the IPIPE is bypassed, and 2592x1944 raw bayer image is saved to SDRAM, and convert to YUV image by splitting in two part because of the 2176 limits.

In my understanding, all this can be done in continues mode. Does there any example to show how to read raw data from SDRAM in continues mode ?

Best regards

Hi Louis,

Assuming you are using PSP 2.10.00.14 for DM365 and using the LSP driver for VPFE (ISIF, previewer etc..), your required workflow can work only in following condition:

1. Use ISIF-->DDR(Bayer output)-->IPIPEIF-->IPIPE-->RSZ-->DDR (YUV output)

2. Decimation is turned on in IPIPEIF

3. Previewer and Resizer are not used in chained mode from driver perspective

4. Continuous mode of operation is used. But then in continuous mode, the driver does not tell you the DDR buffer details where the bayer data would be lying. You have to modify the interrupt handling for VPSS interrupt in your LSP driver to give out information of the MMAP buffer used for bayer data.

BTW, in this mode, you are going to use a lot of DDR bandwidth as Juan pointed out. I can suggest that you use the ISIF-->IPIPEIF-->IPIPE-->RSZ-->DDR path for your regular data flow, with decimation in IPIPEIF on.

As and when you get the interrupt for doing a raw data capture, you can stop the above data flow and program the ISIF to write to DDR and do conversion to YUV data by splitting the image. This would need an extra IOCTL to be implemented, specifically for this usecase. BTW, the splitting of image and converting to YUV in those split slices need some extra logic and we do not have any example code in DVSDK applications, to achieve that. It might be a decent enough exercise to get the 5MP YUV data output from the bayer data in DDR.

Regards,

Anshuman

hi, Anshuman

Thank you for your answer!

We have modified the example of "do_preview_resize.c" in PSP_02_10_00_14 to get 5MP YUV image by splitting the raw image.  BUT, this is done in Single Shot mode. 

In Continuous mode, how to input RAW image from DDR to get YUV image, regardless the image size? 

DDR(Bayer output)-->IPIPEIF-->IPIPE-->RSZ-->DDR (YUV output)

Best regards

Louis, John,

For supporting line width of 2592 pixels, you need to run the IPIPE and resizer twice in vertical slices so that each line width is less than 2176 pixels.

in continuous mode, the ISIF (input source) will always give data in complete lines of 2592 pixels each. There is no way you can get half vertical slice from the sensor separately in the continuous mode. You need to store the full frame data in the DDR and then use half vertical slice. This can be done using one shot mode only. 

I hope the description makes the usage clear.

Regards,

Anshuman

Thank you for the reply.

I have found a couple examples of running the ipipe in two vertical slices, as you described. However, the problem I'm having right now is that I can't even get the RAW data from the image sensor. It works fine when I run it at 720p, but when I increase this to 2592x1944 the VIDINT0 interrupt stops happening, so I can never get the image data. I'm having trouble figuring out exactly what caused this. 

Thanks,

John

John,

Good to know that you can make progress. For this problem, i can think of some probable reasons as follows:

1. Check the VDINT0 register of ISIF. If it is more than 1944, then you are not going to get any interrupts. It sets the number of lines that should come after VD signal, before interrupt can be generated.

2. Check the PCLK input to DM365 and ensure that clock is coming. If there is no clock, there will be no interrupt.

3. Check the VD and HD width settings

Regards,

Anshuman

Thank you for the reply.

In response to your suggestions:

1. Using the ccdc_readregs() function I printed the value of the registers after executing the ccdc_config_raw() function. For the VIDINT0 function, when running in 720p mode (which works), the value was set to 0xc, while for 2592x1944 VIDINT0 was 0x20. This value is set in the ccdc_config_raw() function with the following code:

                val = params->win.height / 60;

                mdelay(5);

                regw(136, VDINT0);

                regw(val, VDINT0);      // Change by Gaurav

                //regw(0, VDINT0);      // Change by Gaurav

                mdelay(5);

                regw(0, VDINT1);

I'm not exactly sure how this relates to the values that I am reading back, but there is a difference between the two resolution settings.

2. I probed the PCLK as well as some data lines from the imager, and have verified that data is being sent to the dev board.

3. For both resolutions, VD and HD are 0. The only other differences between the registers for the two resolutions are as follows:

720p...                               2592x1944...

Reading 0x4ff to NPH...      Reading 0xa1f to NPH... 

Reading 0x2cf to NLV...     Reading 0x797 to NLV... 

Reading 0x50 to HSIZE...   Reading 0xa2 to HSIZE...  

I'll keep looking into this stuff to see if I can figure anything out. Thanks again for any help.

Hi Louis, I've got the same problem, did you find out what was wrong? I would really appreciate if you could guide me in the right direction.

Many thanks.

Hi Louis, 

I am trying to run same demo "capture_prev_rsz_onthe_fly_bayer_mew.c". And I am stuck at DQBUF. I tried to capture having image size of  1920x1080. Can you tell me which changes you have done to make this application working.

Regards,

Jemish