H264ENC codec performance on OMAPL138

For greater clarity, I give pieces of our code associated with the filling of the codec parameters.

hVE->encoder = VIDENC1_create(hEngine, “h264enc”, params);

with params:

    params->size = sizeof (VIDENC1_Params);

    params->encodingPreset = XDM_HIGH_SPEED;

    params->rateControlPreset = IVIDEO_NONE;

    params->maxHeight = 480;

    params->maxWidth = 720;

    params->maxFrameRate = 30000;

    params->maxBitRate = 2097152;

    params->dataEndianness = XDM_BYTE;

    params->maxInterFrameInterval = 1;

    params->inputChromaFormat = XDM_YUV_420P;

    params->inputContentType = IVIDEO_PROGRESSIVE;

    params->reconChromaFormat = XDM_CHROMA_NA;

status = VIDENC1_control(hVE->encoder, XDM_SETPARAMS, dynParams, &encStatus);

with dynParams:

    dynParams->size = sizeof (VIDENC1_DynamicParams);

    dynParams->inputHeight =  480;

    dynParams->inputWidth = 720;

    dynParams->refFrameRate = 30000;

    dynParams->targetFrameRate = 30000;

    dynParams->targetBitRate = 2097152;

    dynParams->generateHeader = XDM_ENCODE_AU;

    dynParams->captureWidth = 0;

    dynParams->forceFrame = IVIDEO_NA_FRAME;

    dynParams->interFrameInterval = 1;

    dynParams->mbDataFlag = 0;

and

    encStatus.size = sizeof (VIDENC1_Status);

    encStatus.data.buf = NULL;

retVal = VIDENC1_process(vHandle->encoder,

                &vHandle->inBufDesc, &vHandle->outBufDesc,

                &inArgs, &outArgs);

 with

    inArgs.size = sizeof (IVIDENC1_InArgs);

    outArgs.size = sizeof (IVIDENC1_OutArgs);

Input/Output buffers were allocated through CMEM Memory_alloc():

    allocParams.type = Memory_CONTIGPOOL;

    allocParams.flags = Memory_NONCACHED;

    allocParams.align = BUFALIGN;

    allocParams.seg = 0;

    Buffer = (XDAS_Int8 *) Memory_alloc(2000000, &allocParams);

Andrey:

   This post   http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/29482/208713.aspx  estimates 14 fps for D1-NTSC on OMAPL138.

   However, the DaVinci family of processors can meet 30 fps for H264:  http://processors.wiki.ti.com/index.php/C64x%2B_and_Davinci_codec_performance_tables

Hi Anthony,

Thanks for helpful links.

I have read Marianas post with estimations from http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/29482/208713.aspx. I was interested by presented estimations for MPEG4 encoder:

"For MPEG 4 encoder:

Number of channels  1

Max resolution D1

Max bit rate 5Mbps

FPS 30 (see Comment)

Profiles supported SP

But these numbers were achieved reading and writting to a file, so you can expect a 10 - 20 % of decrease when using  the hardware."

I try to use mpeg4enc (codecs-omapl138_4_02_00_00\packages\ti\sdo\codecs\mpeg4enc\) instead of h264enc for encoding 720x480 frames, but I observe fail execution of VIDENC1_create() function (it returns NULL).

I use following parameters:

    params->size = sizeof (VIDENC1_Params);

    params->encodingPreset = 2;

    params->rateControlPreset = 5;

    params->maxHeight = 480;

    params->maxWidth = 720;

    params->maxFrameRate = 30000;

    params->maxBitRate = 20000000;

    params->dataEndianness = XDM_BYTE;

    params->maxInterFrameInterval = 1;

    params->inputChromaFormat = 1;

    params->inputContentType = IVIDEO_PROGRESSIVE;

    params->reconChromaFormat = XDM_CHROMA_NA;

    dynParams->size = sizeof (VIDENC1_DynamicParams);

    dynParams->intraFrameInterval = 30;

    dynParams->inputHeight = params->maxHeight;

    dynParams->inputWidth = params->maxWidth;

    dynParams->targetFrameRate = params->maxFrameRate;

    dynParams->refFrameRate = params->maxFrameRate;

    dynParams->targetBitRate = params->maxBitRate;

    dynParams->generateHeader = XDM_ENCODE_AU;

    dynParams->captureWidth = 0;

    dynParams->forceFrame = IVIDEO_NA_FRAME;

    dynParams->mbDataFlag = 0;

    dynParams->interFrameInterval = params->maxInterFrameInterval;

same as in example application (\codecs-omapl138_4_02_00_00\packages\ti\sdo\codecs\mpeg4enc\app\Client\Test\Src\) in case of enabled XDM_BASE_CLASS_ONLY.  The difference is that I use the Codec Engine API.

Could you please tell me where is my mistake?
May be you can give me simple example of codec engine based application, which uses mpeg4enc codec?

Thanks,

Andrey

Hello Andrey:

   For an MPEG4 encoder example using CE, in DVSDK v4.03 (the latest), I see a DMAI component which uses codec engine to invoke various codecs.  

   See in ~/ti-dvsdk_omapl138-evm_04_03_00_06/dmai_2_20_00_15/packages/ti/sdo/dmai/

           ce/Venc1.c
           apps/video_encode_io1/appMain.c
           apps/video_encode_io_multich1/appMain.c

   The DMAI documentation should give instructions on how to build and invoke the application.  If that works for the MPEG4 encoder, you can add your parameters incrementally to the DMAI application and see what breaks.

   Often, when a codec fails to create, it is usually either the algorithm parameters or failure to acquire resources (DSKT2 memory, or DMA).  If the parameters are the same as the test app, then it might be a resource allocation failure. 

   You could enable Codec Engine and Framework Components trace to find out where the failure is occuring.

  http://processors.wiki.ti.com/index.php/Framework_Components_FAQ

  http://processors.wiki.ti.com/index.php/FC_Config_Updates#Debug_and_Trace_settings

  Running your CE application with the environment variable CE_DEBUG=3, should show all the trace.

  http://processors.wiki.ti.com/index.php/Codec_Engine_FAQ#Runtime_Troubleshooting

Hi Gil,

We have just now returned to this problem with mpeg4enc codec (on OMAPL138 board).

We took advantage of your advice and looked at dmai examples:
           apps/video_encode_io1/appMain.c
           apps/video_encode_io_multich1/appMain.c

At the first,
we have build dmai apps, but this required making changes into files:
1) "ti-dvsdk_omapl138-evm_04_03_00_06/dmai_2_20_00_15/Rules.make" (our version is in attachment),
2) "ti-dvsdk_omapl138-evm_04_03_00_06/dmai_2_20_00_15/packages/ti/sdo/dmai/apps/Makefile.app" (our version is in attachment)
as they are obsolete for content of dvsdk_omapl138-evm_04_03_00_06_setuplinux. As we understand, these applications were not tested on OMAPL138 with dvsdk ver. 04_03_00_06.

At the second,

we have run "video_encode_io1" application without changes with input video file in YUV422ILE format. Input file was successfully processed.

But we were confused by the fact that only XDM_YUV_422ILE input format are used for OMAPL138 board in all examples

as in  "video_encode_io1":

"Int appMain(Args * args)

{

...

    /* Set up codec parameters depending on device */
    switch (device) {
        case Cpu_Device_DM6467:
            params.inputChromaFormat = XDM_YUV_420SP;
            params.reconChromaFormat = XDM_CHROMA_NA;
            break;
        case Cpu_Device_DM355:
            params.inputChromaFormat = XDM_YUV_422ILE;
            params.reconChromaFormat = XDM_YUV_420P;
            break;            
        case Cpu_Device_DM365:
        case Cpu_Device_DM368:
            params.inputChromaFormat = XDM_YUV_420SP;
            params.reconChromaFormat = XDM_YUV_420SP;
            break;
        case Cpu_Device_DM3730:
            params.rateControlPreset = IVIDEO_STORAGE;
            params.inputChromaFormat = XDM_YUV_422ILE;
            break;
        default:
            params.inputChromaFormat = XDM_YUV_422ILE;
            break;

...

    /* Which color space to use in the graphics buffers depends on the device */
    colorSpace = ((device == Cpu_Device_DM6467)||
                  (device == Cpu_Device_DM365) ||
                  (device == Cpu_Device_DM368)) ? ColorSpace_YUV420PSEMI :
                                               ColorSpace_UYVY;

...
}"

However, in "ti-dvsdk_omapl138-evm_04_03_00_06/codecs-omapl138_4_02_00_00/packages/ti/sdo/codecs/mpeg4enc/docs/MPEG4_Encoder_DM6446_UserGuide.pdf" - section "4.2.1.9 IVIDENC1_Params" It's said:

"Field: inputChromaFormat 

Data Type: XDAS_Int32

Input/Output: Input

Description:  Input chroma format. See XDM_ChromaFormat enumeration for details.
    Values supported = 1, 3 , and 4
    Minimum value = 1
    Maximum value = 4
    Default value = XDM_CHROMAFORMAT_DEFAULT"

Xdm.h:

"typedef enum {
    XDM_CHROMA_NA = -1,     /**< Chroma format not applicable. */
    XDM_YUV_420P = 1,           /**< YUV 4:2:0 planer. */
    XDM_YUV_422P = 2,           /**< YUV 4:2:2 planer. */
    XDM_YUV_422IBE = 3,       /**< YUV 4:2:2 interleaved (big endian). */
    XDM_YUV_422ILE = 4,       /**< YUV 4:2:2 interleaved (little endian). */
    XDM_YUV_444P = 5,           /**< YUV 4:4:4 planer. */
    XDM_YUV_411P = 6,          /**< YUV 4:1:1 planer. */
    XDM_GRAY = 7,                   /**< Gray format. */
    XDM_RGB = 8,                     /**< RGB color format. */
    XDM_YUV_420SP = 9,        /**< YUV 420 semi_planar format.(Luma 1st plane,
                                                      *   CbCr interleaved 2nd plane)  */
    XDM_ARGB8888 = 10,      /**< Alpha plane. */
    XDM_RGB555 = 11,           /**< RGB 555 color format. */
    XDM_RGB565 = 12,           /**< RGB 565 color format. */
    XDM_YUV_444ILE = 13,    /**< YUV 4:4:4 interleaved (little endian). */
    /** Default setting. */
    XDM_CHROMAFORMAT_DEFAULT = XDM_YUV_422ILE
} XDM_ChromaFormat;"

At the third,

we have changed "ti-dvsdk_omapl138-evm_04_03_00_06/dmai_2_20_00_15/packages/ti/sdo/dmai/apps/video_encode_io1/appMain.c" for reading file through readFrame420P() and processing with params.inputChromaFormat = XDM_YUV_420P and colorSpace =ColorSpace_YUV420P (our version is in attachment).

We have used "/ti-dvsdk_omapl138-evm_04_03_00_06/codecs-omapl138_4_02_00_00/packages/ti/sdo/codecs/mpeg4enc/app/Client/Test/TestVecs/Input/davincieffect_qcif.yuv" file as input file.

And we observed following behaviour (full logs 420p_with_ce_and_dmai_log.txt and 420p_without_ce_and_dmai_log.txt are in attachments):

"...

 Frame 0: Read 420P frame size 38016 (176x144) from file
Call Venc1_process()
@7,886,466us: [+7 T:0x4000e2f0 S:0xbee1865c] ti.sdo.dmai - [Venc1] Unsupported color format of input buffer
Failed to encode video buffer

...
End of application."

Could you please explain to us why dmai not support YUV420P color format, despite the fact that mpeg4enc codec documentation announced support of YUV420P  format?

0383.video_encode_io1.zip

Hi Gil

We have analyzed dmai code and found that following checks exist in function Venc1_process():

Int Venc1_process(Venc1_Handle hVe, Buffer_Handle hInBuf, Buffer_Handle hOutBuf)

{

....

    /* Point to the color planes depending on color space format */
    if (BufferGfx_getColorSpace(hInBuf) == ColorSpace_YUV420PSEMI) {
        inBufDesc.bufDesc[0].bufSize    = hVe->minInBufSize[0];
        inBufDesc.bufDesc[1].bufSize    = hVe->minInBufSize[1];

        inBufDesc.bufDesc[0].buf        = inPtr;
        inBufDesc.bufDesc[1].buf        = inPtr + Buffer_getSize(hInBuf) * 2/3;
        inBufDesc.numBufs               = 2;
    }
    else if (BufferGfx_getColorSpace(hInBuf) == ColorSpace_UYVY) {
        inBufDesc.bufDesc[0].bufSize    = Buffer_getSize(hInBuf);
        inBufDesc.bufDesc[0].buf        = inPtr;
        inBufDesc.numBufs               = 1;
    }
    else {
        Dmai_err0("Unsupported color format of input buffer\n");
        return Dmai_EINVAL;
    }
...

}

We have added following case into function Venc1_process():

...

    else if (BufferGfx_getColorSpace(hInBuf) == ColorSpace_YUV420P) {
        inBufDesc.bufDesc[0].bufSize    = hVe->minInBufSize[0];
        inBufDesc.bufDesc[1].bufSize    = hVe->minInBufSize[1];

        inBufDesc.bufDesc[0].buf        = inPtr;
        inBufDesc.bufDesc[1].buf        = inPtr + Buffer_getSize(hInBuf) * 2/3;
        inBufDesc.numBufs               = 2;
    }

...

And we observed following behaviour with such fix:

...

Frame 0: Read 420P frame size 38016 (176x144) from file
Call Venc1_process()
@6,590,207us: [+0 T:0x400002f0 S:0xbea7160c] ti.sdo.ce.video1.VIDENC1 - VIDENC1_process> Enter (handle=0x67c28, inBufs=0xbea71768, outBufs=0xbea7175c, inArgs=0xbea7174c, outArgs=0xbea716d4)
@6,590,485us: [+4 T:0x400002f0 S:0xbea7158c] CV - VISA_getMaxMsgSize(0x67c28): returning 0x1000
@6,590,688us: [+5 T:0x400002f0 S:0xbea71594] CV - VISA_allocMsg> Allocating message for messageId=0x00021043
@6,590,885us: [+0 T:0x400002f0 S:0xbea71564] OM - Memory_getBufferPhysicalAddress> Enter(virtAddr=0x40c6f000, size=25344)
@6,591,084us: [+1 T:0x400002f0 S:0xbea71564] OM - Memory__getPhysicalAddress> Enter(virtAddr=0x40c6f000, size=25344)
@6,591,277us: [+1 T:0x400002f0 S:0xbea71564] OM - Memory__getPhysicalAddress> found in cb(Sc=0x40c6f000, Ec=0x40c78480, Ss=0x40c6f000, Es=0x40c75300, PSc=0xc2000000)
@6,591,539us: [+1 T:0x400002f0 S:0xbea71564] OM - Memory__getPhysicalAddress> returning physAddr=0xc2000000
@6,591,729us: [+0 T:0x400002f0 S:0xbea71564] OM - Memory_getBufferPhysicalAddress> return (0xc2000000)
@6,591,915us: [+0 T:0x400002f0 S:0xbea71564] OM - Memory_getBufferPhysicalAddress> Enter(virtAddr=0x40c75300, size=6336)
@6,592,103us: [+1 T:0x400002f0 S:0xbea71564] OM - Memory__getPhysicalAddress> Enter(virtAddr=0x40c75300, size=6336)
@6,592,288us: [+1 T:0x400002f0 S:0xbea71564] OM - Memory__getPhysicalAddress> found in cb(Sc=0x40c6f000, Ec=0x40c78480, Ss=0x40c75300, Es=0x40c76bc0, PSc=0xc2000000)
@6,923,317us: [+1 T:0x400002f0 S:0xbea71564] OM - Memory__getPhysicalAddress> returning physAddr=0xc2006300
@6,923,572us: [+0 T:0x400002f0 S:0xbea71564] OM - Memory_getBufferPhysicalAddress> return (0xc2006300)
@6,923,776us: [+0 T:0x400002f0 S:0xbea71564] OM - Memory_getBufferPhysicalAddress> Enter(virtAddr=0x40c8b000, size=101376)
@6,923,972us: [+1 T:0x400002f0 S:0xbea71564] OM - Memory__getPhysicalAddress> Enter(virtAddr=0x40c8b000, size=101376)
@6,924,160us: [+1 T:0x400002f0 S:0xbea71564] OM - Memory__getPhysicalAddress> found in cb(Sc=0x40c8b000, Ec=0x40ca3c00, Ss=0x40c8b000, Es=0x40ca3c00, PSc=0xc200a000)
@6,924,359us: [+1 T:0x400002f0 S:0xbea71564] OM - Memory__getPhysicalAddress> returning physAddr=0xc200a000
@6,928,494us: [+0 T:0x400002f0 S:0xbea71564] OM - Memory_getBufferPhysicalAddress> return (0xc200a000)
@6,928,799us: [+0 T:0x400002f0 S:0xbea715ac] CV - VISA_call(visa=0x67c28, msg=0x40bfdc80): messageId=0x00021043, command=0x0
@6,929,029us: [+0 T:0x400002f0 S:0xbea71574] OC - Comm_put> Enter(queue=0x2, msg=0x40bfdc80)
@6,929,322us: [+0 T:0x400002f0 S:0xbea71574] OC - Comm_put> return (0)
@6,929,536us: [+0 T:0x400002f0 S:0xbea7156c] OC - Comm_get> Enter(queue=0x10001, msg=0xbea71624, timeout=-1)
@6,930,464us: [+0 T:0x400002f0 S:0xbea7156c] OC - Comm_get> MSGQ_get() status=0x8000, return (0)
@6,930,756us: [+0 T:0x400002f0 S:0xbea714fc] OC - Comm_put> Enter(queue=0x0, msg=0x40bfcc80)
@6,931,045us: [+0 T:0x400002f0 S:0xbea714fc] OC - Comm_put> return (0)
@6,931,532us: [+0 T:0x400002f0 S:0xbea714f4] OC - Comm_get> Enter(queue=0x10000, msg=0xbea71594, timeout=-1)
@6,931,813us: [+0 T:0x400002f0 S:0xbea714f4] OC - Comm_get> MSGQ_get() status=0x8000, return (0)
[DSP] @3,766,191tk: [+5 T:0xc33dab94 S:0xc33dee84] CN - NODE> 0xc33da628(mpeg4enc#0) call(algHandle=0xc33da6f0, msg=0xc3507c80); messageId=0x00021043
[DSP] @3,766,262tk: [+0 T:0xc33dab94 S:0xc33ded54] OM - Memory_cacheInv> Enter(addr=0xc2000000, sizeInBytes=25344)
[DSP] @3,766,343tk: [+0 T:0xc33dab94 S:0xc33ded54] OM - Memory_cacheInv> return
[DSP] @3,766,379tk: [+0 T:0xc33dab94 S:0xc33ded54] OM - Memory_cacheInv> Enter(addr=0xc2006300, sizeInBytes=6336)
[DSP] @3,766,437tk: [+0 T:0xc33dab94 S:0xc33ded54] OM - Memory_cacheInv> return
[DSP] @3,766,473tk: [+0 T:0xc33dab94 S:0xc33ded54] OM - Memory_cacheInv> Enter(addr=0xc200a000, sizeInBytes=101376)
[DSP] @3,766,640tk: [+0 T:0xc33dab94 S:0xc33ded54] OM - Memory_cacheInv> return
[DSP] @3,766,681tk: [+0 T:0xc33dab94 S:0xc33ded1c] ti.sdo.ce.video1.VIDENC1 - VIDENC1_process> Enter (handle=0xc33da6f0, inBufs=0xc33dedbc, outBufs=0xc33dee8c, inArgs=0xc3507e04, outArgs=0xc3507e10)
[DSP] @3,766,768tk: [+5 T:0xc33dab94 S:0xc33decfc] CV - VISA_enter(visa=0xc33da6f0): algHandle = 0xc33da728
[DSP] @3,766,818tk: [+0 T:0xc33dab94 S:0xc33decdc] ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(alg=0xc33da728)
[DSP] @3,766,867tk: [+0 T:0xc33dab94 S:0xc33decdc] ti.sdo.ce.alg.Algorithm - Algorithm_activate> Exit
[DSP] @3,766,913tk: [+5 T:0xc33dab94 S:0xc33decfc] CV - VISA_exit(visa=0xc33da6f0): algHandle = 0xc33da728
[DSP] @3,766,962tk: [+0 T:0xc33dab94 S:0xc33decdc] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter(alg=0xc33da728)
[DSP] @3,767,011tk: [+0 T:0xc33dab94 S:0xc33decdc] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Exit
[DSP] @3,767,059tk: [+0 T:0xc33dab94 S:0xc33ded1c] ti.sdo.ce.video1.VIDENC1 - VIDENC1_process> Exit (handle=0xc33da6f0, retVal=0xffffffff)
[DSP] @3,767,116tk: [+5 T:0xc33dab94 S:0xc33dee84] CN - NODE> returned from call(algHandle=0xc33da6f0, msg=0xc3507c80); messageId=0x00021043
[DSP] @3,768,217tk: [+0 T:0xc33d5b6c S:0xc33d9b2c] CR - processRmsCmd(0xc3506ca8, 4056): cmd = 5
[DSP] @3,768,262tk: [+0 T:0xc33d5b6c S:0xc33d9b2c] CR - remote time = 0x0, trace buffer size = 4032
@6,942,000us: [+0 T:0x400002f0 S:0xbea7152c] CE - Engine_fwriteTrace> returning count [2072]
@6,942,234us: [+0 T:0x400002f0 S:0xbea715ac] CV - VISA_call Completed: messageId=0x00021043, command=0x0, return(status=-1)
@7,273,031us: [+5 T:0x400002f0 S:0xbea7159c] CV - VISA_freeMsg(0x67c28, 0x40bfdc80): Freeing message with messageId=0x00021043
@7,273,304us: [+0 T:0x400002f0 S:0xbea7160c] ti.sdo.ce.video1.VIDENC1 - VIDENC1_process> Exit (handle=0x67c28, retVal=0xffffffff)
@7,273,521us: [+2 T:0x400002f0 S:0xbea7165c] ti.sdo.dmai - [Venc1] VIDENC1_process() ret -1 inId 0 outID 0 generated 0 bytes
@7,273,724us: [+7 T:0x400002f0 S:0xbea7165c] ti.sdo.dmai - [Venc1] VIDENC1_process() failed with error (-1 ext: 0x8000)
Failed to encode video buffer

...

We observe a similar behavior for the direct use of Codec Engine without dmai.

Full log is in attachment (420p_with_ce_and_dmai_log_and_fix_venc1.txt).

Our code changes and binary are in attachments too (appMain.c and Venc1.c and video_encode_io1_omapl138.x470MV)

Also I have attached log (422ile_with_ce_and_dmai_log_and_fix_venc1.txt) with successful execution of  "video_encode_io1" with 422ILE input format.

8686.video_encode_io1_fix_venc1.zip

Could you please answer what input color formats are supported by mpeg4enc codec for OMAPL138 board?

Andrey:

    This *is* the right forum for this question, and hopefully one of the video codec experts (or DMAI developers) can answer.

Regards,

- Gil

Sorry Gil, I'm a little misunderstood your answer. I can wait for a response from experts in this topic, or should create a new one in other subforum, or should create a new one in this subforum ("Multimedia Software Codecs")?

PS: I was confused by the phrase "This *is* the right forum ..." - Is this failed link to a different subforum?

Thanks,

Andrey

Andrey:

   I meant to suggest to wait for a response from a codec expert in this forum.

Regards,

- Gil

We have finally found root cause of VIDENC1_process error and have fixed it in Venc1.c. Our changes, executable binary and input and output video are in attachment.

Now we do not obtain errors during video processing with YUV_420P color format. But output video stream after mpeg4enc codec processing is not correct. Image blurs and as a result completely corrupted.

Similar incorrect output video stream was obtained when we launch original (without our changes) video_encode_io1example with YUV_422ILE input format.

We still need your help.

6332.video_encode_io1_fix_venc1_v2.zip

Thanks,

Andrey