[MX53] CSC runs much slower than the value shown in datasheet

[OD]

Dear all. I have a problem with the Image Converter.

In my situation, I use VPU to decode a H.264 stream into YUV bitmap,

convert its color space to RGB32 without change the size, and make some draw necessary before

switch the frame buffer offset to display the final image.

Although it seems to be a common task in video playback scene, and the datasheet

says it can make output 75M pixels per second, I've found that IC just can't deal with 

any conversion more than 35M/s (eg 1440x900@30FPS). There is no additional

memory copy between decoding and conversion phase, I've no idea why it runs so slowly,

can someone please give me any useful information ?

Best regards

[OD]

I'll write some codes to test it, you did me a great favor :)

Best regards

[qiang_li-mpu_se]

The default code of mxc_vpu_test can output the UYVY pixel to screen direct, when the code set V4l2 output display to 3 (Foreground, fb2), the mxc_vpu_test will check the fb2 pixel format, it is YUV format, so V4l2 output driver will render the decoded video to YUV and put to fb2 for display. FB2 is the overlay surface for display, it can be YUV but the fb0 can still be RGB, the IPU hardware can combine them and show on display.
And when the code set V4l2 output display to 4 (Background, fb0), the mxc_vpu_test will find the framebuffer is in RGB format, then it will tell V4l2 output driver to render the decoded video to RGB format.

[OD]

Thanks a lot, but I can't get the point ^_^;

Is there any way to put UYVY pixel direct to screen, and what does PP exactly means ?

After try I figured that buffered stream mode in V4L2 can't meet my requirement cause I need them work as live scene like video conference, currently I use two IPU tasks for double buffering, there output address were assigned to start address of FB0 and FB0 + (Width * Height * BPP), after a frame was decoded, firstly update task 1 to convert pixel format into RGB32, draw something on it, and set FBIOPAN_DISPLAY via ioctl to swap display, then take next frame on task 2.

I read the manual and code but still can't find out the most efficient way which can fit the requirement, please help me.

Best regards

[qiang_li-mpu_se]

Yes, the default mxc_vpu_test will output the video to FB2 with UYVY format, but we can changed the "display.c" in mxc_vpu_test, in function v4l_display_open(), updated the code as followed:

 out = 4;   // 3 = FG(fb2); 4 = BG(fb0) ; 5 = DC(fb1)

 err = ioctl(fd, VIDIOC_S_OUTPUT, &out);
 if (err < 0) {
  err_msg("VIDIOC_S_OUTPUT failed\n");
  goto err;
 }

Then PP will resize and CSC the output frame to RGB data.

[OD]

Thanks for your reply, it seems the demo just packed source to YVUV pixels and output them to an overlapped frame buffer instead of converting format, I'll check this out

[qiang_li-mpu_se]

    How do you test it? It seems when using the vpu unit test application "mxc_vpu_test", it can be 30fps for 1080P video stream. The video will be decoded in YUV format and render to RGB frame buffer to show.

    ./mxc_vpu_test.out  -D "-i /1080p.h264 -f 2 -x 0 -w 1920 -h 1080"