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.

H264 encoding of captured video AND how to get 24 bit RGB input video out of VFCC

Guru 10685 points

As title.

I have 2 requirements:

1) I am giving 24 bit RGB888 video into the DM8168 on VIP0 and I need to get this raw video data into ARM memory (no colourspace conversion to 4:2:2 YUV)

2) I need to encode this RGB video stream to H264. I don't mind if it gets converted to YUV 4:2:0 before being given to the VENC component for encoding to H264.

How do I do these 2 things on the same chip? OpenMAX VFCC component only seems to give out 4:2:0 video which is no good for me even though I give it RGB888.

Thanks,

Ralph

  • For (1), this only works with the V4L2 input driver (ti81xxvin).  Working in user pointer mode it can write anywhere in memory as long as it's physically contiguous (Linux framebuffer, OpenMAX buffers, CMEM memory, or just some random bit of physical memory you mmap()ed out of /dev/mem).

    For (2), you need to convert RGB to YUV before feeding it to the encoder.  As far as I know, there is no support for doing this in any of TI's code, so you're stuck with doing it in software.  ARM/NEON works but won't be fast enough for high resolution and framerate.  Both the DSP and the graphics core are probably capable of doing it properly, but I haven't tried either so I'm guessing a bit there.

    - Mark

  • Mark, your input is greatly appreciated and indeed just what I thought.

    I hope I can also get someone from TI to give me an official answer.....

  • Hi,

    i also do the same work with you.i use dm8168 in dvr(3.0) broad . The captured BIOS code in vpssm3 has some relation code with RGB888 input .it's can setect some yuv output format. 

    vpscore_vipResSingleChRgb888.c

    /*
    this file has path allocation logic when input is RGB 24-bit
    */

    #include <ti/psp/vps/core/src/vpscore_vipResPriv.h>

    /*
    Allocate path with RGB888 as input

    Input could be from Port A, or COMP path
    */

  • Hi,

    VIP can support dual out. That is you can get one output in YUV and other in RGB, you can fed this RGB out to display and YUV out to encoder. I am not very well versed with OMX but driver supports this so OMX should support this as well.

  • hi,

    Does any way  to convert  RGB  to  yuv in dvrrdk 3.0 VPSSM3?

  • Not in m2m deiver.

     

    Thx,

    Brijesh

  • shuai, I don't have access to the source code you are talking about so that's not really of use unfortunately. Those files aren't in the EZSDK anyway.

    Brijesh and Hardik, what you said sounds promising but please can you give a source code example of how to implement this second RGB output of the VFCC component?

    I have read both the "TI OpenMAX Development Guide" online and the "OpenMAX User Guide" PDF in the EZSDK but neither document anything to do with RGB output from the VFCC component. This is very important to us. Up till now I was aware that you could have 2 VFCC components to account for VIP0 and VIP1 but I was unaware that you could have 2 output ports with different colourspaces/colour formats.

    Thanks for your support,

    Ralph

  • Oh,i use the DVRRDK3.0.

  • Still waiting for help to get the second output of VFCC working as RGB 4:4:4 (or even YUV 4:4:4 would do for me).....

    I've tried guessing how to setup the second output port. Please see below.

    Thanks,

    Ralph

    * Here are my settings at present. No idea what "stride" should be for RGB 4:4:4.

        // VFCC output port 0.
        paramPort.nPortIndex = OMX_VFCC_OUTPUT_PORT_START_INDEX;
        OMX_GetParameter(pAppData->pCapHandle, OMX_IndexParamPortDefinition, &paramPort);
        paramPort.nPortIndex = OMX_VFCC_OUTPUT_PORT_START_INDEX;
        paramPort.format.video.nFrameWidth = pAppData->nWidth;
        paramPort.format.video.nFrameHeight = pAppData->nHeight;
        paramPort.format.video.nStride = pAppData->nWidth;
        paramPort.nBufferCountActual = IL_CLIENT_CAPTURE_OUTPUT0_BUFFER_COUNT;
        paramPort.format.video.eCompressionFormat = OMX_VIDEO_CodingUnused;
        paramPort.format.video.eColorFormat = OMX_COLOR_FormatYUV420SemiPlanar;    // YUV 420
        paramPort.nBufferSize = (paramPort.format.video.nStride * pAppData->nHeight * 3) >> 1;
        OMX_SetParameter(pAppData->pCapHandle, OMX_IndexParamPortDefinition, &paramPort);

        // VFCC output port 1.
        paramPort.nPortIndex = OMX_VFCC_OUTPUT_PORT_START_INDEX + 1;
        OMX_GetParameter(pAppData->pCapHandle, OMX_IndexParamPortDefinition, &paramPort);
        paramPort.nPortIndex = OMX_VFCC_OUTPUT_PORT_START_INDEX + 1;
        paramPort.format.video.nFrameWidth = pAppData->nWidth;
        paramPort.format.video.nFrameHeight = pAppData->nHeight;
        paramPort.format.video.nStride = pAppData->nWidth;            // What should this be?
        paramPort.nBufferCountActual = IL_CLIENT_CAPTURE_OUTPUT1_BUFFER_COUNT;
        paramPort.format.video.eCompressionFormat = OMX_VIDEO_CodingUnused;
        paramPort.format.video.eColorFormat = OMX_COLOR_Format24bitRGB888;    // RGB 444
        paramPort.nBufferSize = pAppData->nWidth * pAppData->nHeight * 3;
        OMX_SetParameter(pAppData->pCapHandle, OMX_IndexParamPortDefinition, &paramPort);

  • I've checked and my output buffer for port 1 of VFCC is sadly 1920x1080 bytes of Y data followed by 1920x1080x0.5 bytes of UV data. i.e. YUV 420 format data, same as port 0.

    I'm going to check through some NDA source code I have for the VPSS and see what I come up with. Hopefully someone from TI can help me though....

  • Discovered that the source code I had was only for the closed OpenMAX TI software libraries and not for VPSS. :-(

    On a side note, I did do a binary diff on the media controller binaries for VPSS with OpenMAX (dm816x_hdvpss.xem3) and with V4L2 (dm816x_hdvpss_v4l2.xem3) and found that they were practically identical. :-S

    i.e. You can load dm816x_hdvpss_v4l2.xem3 and run OpenMAX encode/decode applications fine....

    Still hoping for an answer from TI.

    Thanks,

    Ralph