This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Dear All:
I tried to encode H.264 in NTSC/PAL resolution (D1).
The input video is coming from TVP-5146 or other TV decoder in YUV422 format (BT656).
SInce H.264 is using YUV420, I need to convert the YUV422 to YUV420.
I realize that there is a 32 byte alignment constraint in the resizer.
Therefore, I set the input and output width of the resizer to 736.
But only the Y layer is OK, the UV layer does not look right.
I also use other resolutions, such as 1280x720 from camera and 640x480
from tv input. These results are ok. Only 720x480 (or 736x480) is not working well.
The following are two parts of my code:
////// config ///////
rsz_ss_config.input.image_width = 736;
rsz_ss_config.input.image_height = 480;
rsz_ss_config.input.ppln = rsz_ss_config.input.image_width + 8;
rsz_ss_config.input.lpfr = rsz_ss_config.input.image_height + 10;
rsz_ss_config.input.pix_fmt = IPIPE_UYVY;
rsz_ss_config.output1.width = 736;
rsz_ss_config.output1.height = 480;
rsz_ss_config.output1.pix_fmt = IPIPE_YUV420SP;
rsz_ss_config.output1.enable = 1;
rsz_ss_config.output2.enable = 0;
rsz_chan_config.oper_mode = IMP_MODE_SINGLE_SHOT;
rsz_chan_config.chain = 0;
rsz_chan_config.len = sizeof(struct rsz_single_shot_config);
rsz_chan_config.config = &rsz_ss_config;
if (ioctl(rsz_fd, RSZ_S_CONFIG, &rsz_chan_config) < 0) {
fprintf(stderr, "Error in setting configuration in resizer\n");
close(rsz_fd);
return -1;
}
////// resize //////
bzero(&convert, sizeof(convert));
convert.in_buff.buf_type = IMP_BUF_IN;
convert.in_buff.index = -1;
convert.in_buff.offset = (unsigned int)src;
convert.in_buff.size = 736 * 480 * 2;
convert.out_buff1.buf_type = IMP_BUF_OUT1;
convert.out_buff1.index = -1;
convert.out_buff1.offset = (unsigned int)dst;
convert.out_buff1.size = 736 * 480 * 3 / 2;
if (ioctl(rsz_fd, RSZ_RESIZE, &convert) < 0) {
fprintf(stderr, "Error in doing resize\n");
return -1;
}
The following picture is a snapshot of the video.
The added OSD is OK, because I added it in my program.
It is not coming from the original video.
As you can see, although the video looks like B/W,
but there are some very light blue and red strips crossing the video.
Is there anything I need to change for the resizer or anything else?
Any comment will be appreciated.
Ray
Hi,
What is the resolution of your input YUV422 data in DDR? Is it 720x480 or 736x480? Can you share your YUV422 input data itself?
Regards,
Anshuman
Dear Anshuman:
The input data is 720x480 in DDR.
I think I can save the YUV422 data for analysis.
However, I write a software YUV422 to YUV420 semi subroutine and it works well.
It means the UYVY (YUV422) input data shall be fine.
If necessary, I can save and provide the input video data.
Best regards,
Ray
Hi,
Sorry for the delay. Is there any further progress on this issue?
Regards,
Anshuman
Dear Anshuman:
No progress so far.
Do you have some sample code I can try?
Later I will grab the original YUV422 and YUV420 semi after resizer to you for analysis.
regards,
Ray
Hi,
Have you used the sampel codes in the PSP package already? It has do_resize_42x sample code that can be used.
Regards,
Anshuman
Dear Anshuman:
Yes. But the dimension is 1280x720 (720p).
It works well with 1280x720, but does not work with 720x480.
regards,
Ray
Your settings look fine. Why cant you just save the input YUV data and output YUV data?
And where are you viewing the output? Does your YUV viewer support YUV420SP data?
Regards,
Anshuman
Hi,
The problem has been avoided.
Because of the aligment problem, I had the difficulty of locating the
correct position of YUV420 data, especially for UV.
Now I am using 736 instead of 720 to avoid this problem.
Best regards,
Ray
Good to know your problem is resolved. I thought we checked earlier that you are doing 736 pixels per line capture, but may be i misunderstood.
IPIPE/RSZ output has to be aligned to 32byte boundary and hence the number of pixels per line have to be divisble by 32.
Thanks for sharing the update.
Regards,
Anshuman