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.

How to display in the VPBE using the RGB888 mode in 6437EVM?

Other Parts Discussed in Thread: TVP5146

In the video_preview project provided by Bernie Thompson , here I want to thank him.

I am now using the 6437EVM, the VPFE catch one frame by tvp5146 , then  I convert YUV422 into RGB888 mode, then I do some job in this RGB888 frame. Finally, I want to put the RGB888 frame to the VPBE and display in a TV. But when I amended the VPBE in RGB888 mode to output, the video is not proper. When I read an RGB888 image from a *.h file and display in VPBE RGB888 mode, the color is right but the location of each pixel is not so right. The format I fill in the RGB888 frame according to the spru952a.pdf

Can Bernie or somebody kown this problem help me? Thanks very much!

 

  • I am glad to hear that the modified video preview project was helpful. As to the issue at hand, to display RGB888 you would have to configure the display driver to have a window accepting RGB888 data, that is set colorFormat to PSP_VPBE_RGB_888 and bitsPerPixel to FVID_BPP_BITS24, I imagine this is how you are configuring it?

    When you say the color is right but the location is not right, could you post a screen shot of the output you are getting with bad pixel locations?

  • Thank you Bernie to reply so fast.

    Yes, I set colorFormat to PSP_VPBE_RGB_888 and bitsPerPixel to FVID_BPP_BITS24. Then I convert the the frame from the VPFE(frameBuffPtr->frame.frameBufferPtr) to RGB888. But I still have a question that the frame from the VPFE is YUV422, the size of this frame I think is 480*720*2, and when I convert it into RGB888, the size is changed to 480*720*3, do I do it right?

    I also download another TI sample code spraap3a.zip\VPBE_VPFE_Examples\VPBE_example, in which RGB888 mode is used, and it is said that the pitch in vpbeOsdConfigParams must be aligned to 32bit.

    The bad image compared with the original image, it looks interlleaved and is the 2/3 height of the original one, the most significant look is that in the width there are three 1/3 of the original image in the TV.

    The original image:

    The display image:

  • (720 pels * 3 bytes per pel)/32 (=67.5) is not a integer. You need to generate the RGB content in a buffer having each line at an alignment of 32 bytes. In otherwords, at (68 * 32=2176) bytes.

    Hope this helps.

    -Tarak

  • I

    Tarakeshwar Nagajjanavar said:

    (720 pels * 3 bytes per pel)/32 (=67.5) is not a integer. You need to generate the RGB content in a buffer having each line at an alignment of 32 bytes. In otherwords, at (68 * 32=2176) bytes.

    Hope this helps.

    -Tarak

     

    Thanks for reminding. I  knwo how to algin, and I have used 2176 as the pitch. But the input of VPFE is YUV422 and the size of frameBuffPtr->frame.frameBufferPtr is different from the VPBE using RGB888. I know how to make sure the VPBE outputis right.

  • I think Tarak may be on to something here, this looks like a pitch problem, if you take the VPBE example project you mentioned and set the pitch to half its value (line 37, 224 instead of 448) in the RGB888 c file you end up with a similar effect in the RGB888 portion of the display, that is you see three images overlapping each other and stretched vertically by approximately 2/3. The only difference I see is that the colors are now off, but geometrically it seems to match your screen shot.

  • In the spru977a.pdf, when I use CCDC to get a raw data, what format will it be?

    What I want to do is that a frame coming from VPFE, I do some compensation execution in this frame, the executing algorithm is based on RGB888, then I must throw it into VPBE to display in a TV set.

    The video sourse is AV mode, in the video project kindly provided by Bernie, I convert a realtime frame(YUV422) into RGB888 mode, then we do some execution based on RGB888 algorithm, then convert the result into YUV422 and throw it into VPBE, at last display it on a TV. All the execution must be done at realtime. It is hard to do so much execution by 25 fps to get a fluent video.

    The problem is that because there are two convertion to be executed, the speed is slow, we can't get a fluent video, it is just one frame by another. If we what to use it in a product, it seens impossible.

    How can I do in this situation? Can Bernie or someone else answer this question? Thanks very much!

  • Will it be possible to dump the OSD registers from 0x01c7 2600 0x01c7 26fc and share it.

  • When I use 2176 pitch, and copy RGB888 data to framebuff of 720*480 pixels, each time the line(totally 2176) reaches 2160, I move it to the next line(let 2176-2160=16 pitches is zero), the display is OK now!

    Thanks for every ones helps!