DM365: Cropping with Letter Boxing

I understand the principle, but can you please provide an example - we need to know the correct registers to implement this.

There are two main questions (for the two cases - letter boxing in y and in x direction):

1) y - direction (adding black lines): Frame Buffer Start Address and Start address for writing the cropped image (n-th line) to the frame buffer

2) x- direction (adding black columns): like 1), but it is also necessary to increment the line offset by the pixels per line (including the black colums) for writing the smaller image (lower number of x-pixels from the cropped / scaled input) to the buffer - so we also need to know this adjustment.

BR,

RG

What is your input and output data format requirement? YUV422 or YUV420SP mode? Are you using linux LSP driver?

Regards,

Anshuman

Normal 0 21 false false false DE-AT X-NONE X-NONE MicrosoftInternetExplorer4

Dear Anshuman,
here you will find our boundary conditions for input & output format as well as CODEC and Linux LSP driver.

Input Format Requirement:

Resolution: e.g. 1280x1024@60Hz

Cropping Region: e.g. x=335, y =15, dx=900, dy=720 (but: arbitrary cropping regions required – that means that video input and output aspect ratios may be different)

Chroma Subsampling: 4:2:2, YCbCr

Output Format Requirement:

Resolution: 720x576@24Hz or 720x480@24Hz (letter boxing in x- and y-direction in the case that video input and output aspect ratios are different)

Letter Boxing in Region: e.g. x=335, y =15, dx=900, dy=720

Chroma Subsampling: YUV, 4:2:0

CODEC: we are using the MPEG-2 CODEC with Main Level, Main Profile

Yes, we are using Linux LSP driver.

Thank You in advance,

Rudi

Hi,

i want to implement CROP.

have you implemented cropping using VIDEO_S_CROP driver ?

how does it work ? as i was going through the driver it doesn't return any buffer information.

will crop to be done before capture or before encode ?

any input from your side will be helpfull.

--Sujit

Hi,

I have put together the patch for supporting letter box implementation. It is based on LSP 2.10 on DM36x. Please refer to the sample code and the files that need to be modified in the kernel drivers. There is a ppt which depicts on how we have implemented the letterbox.

Regards,

Anshuman

PS: Please mark this post as verified, if you think it has answered your question. Thanks.

Dear Anshuman,

thank you for your response. This describes the implementation for vertical letter boxing (see case 1). Thats nice!

Please see my picture below that describes the situation for horizontal as well as for vertical letter boxing:

In case of vertical letter boxing, shown in representation 1, we can use your implementation.

In case of horizontal letter boxing, shown in representation 2, we need to adjust the starting address for the resizer to fulfill the 32 Byte alignment. For chromaticity information that means a multiple of 64 pixels, assumed that the buffer start address X is fixed.  

Thus we need to use representation 3 to describe the real behavior.  

Due to the black segments at the beginning and at the end of each line the resizer output area is not a continuous memory area anymore. Where can we adjust this necessary offset after each line within the resizer module?

Thank You,

Rudi

Hi,

Rudolf Golser said:

Due to the black segments at the beginning and at the end of each line the resizer output area is not a continuous memory area anymore. Where can we adjust this necessary offset after each line within the resizer module?

Basically, you need to change the line offset for the data. This can be changed in fmt.fmt.pix.bytesperline before the VIDIOC_S_FMT ioctl in capture.c

So for your case, fmt.fmt.pix.width = 640 while fmt.fmt.pix.bytesperline can be 704 or some other number based on the calculation.

regards,

Anshuman

Hello Anshuman,

thank you for this very helpful information.

BR,

Rudi