• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 392 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Production Bundle H.264 Encoder Open Failed

Ning Wang10298
Intellectual 395 points

Hi, all

I am using the TI H.264 production bundle H.264 encoder, v2.0, when openning the encoder algorithm using

VIDENC1_create(....) There will be a CMEM error reporting 'GETPHYS' Error.and the open itself return with a non-NULL value, but later call to VIDENC1_control failes.

But v1.13 encoder using xDM0.9 doing well. The build env is: codec_engine_2_00_01, cmem_2_00_01. Did anyone encounter this problem before ? Is it because the CE version ?

Thanks a lot

 

 

  • 0
    Intellectual 395 points

    Hi, all

    I logged the trace output from the arm side, here is the info

    @0x000b6044:[T:0x402d01f8] ti.sdo.ce.video1.VIDENC1 - VIDENC1_create> return (0x39fd8)
    @0x000b619a:[T:0x402d01f8] ti.sdo.ce.video1.VIDENC1 - VIDENC1_control> Enter (handle=0x39fd8, id=1, params=0xbefffb98 (size=0x30), status=0xbefffaf8 (size=0x9c)
    @0x000b6257:[T:0x402d01f8] CV - VISA_allocMsg> Allocating message for messageId=0x0002003c
    @0x000b62e7:[T:0x402d01f8] OM - Memory_getBufferPhysicalAddress> Enter(virtAddr=0x40114c58, size=251255472)
    @0x000b636c:[T:0x402d01f8] OM - Memory__getPhysicalAddress> Enter(virtAddr=0x40114c58, size=251255472)
    @0x000b63ec:[T:0x402d01f8] OM - Memory__getPhysicalAddress> returning physAddr=0x0
    @0x000b6474:[T:0x402d01f8] OM - Memory_getBufferPhysicalAddress> CMEM_getPhys(0x40114c58) = 0x877abc58.
    @0x000b81b9:[T:0x402d01f8] OM - Memory_getBufferPhysicalAddress> ERROR: user buffer at addr=0x40114c58, size=251255472 is NOT contiguous
    @0x000b8272:[T:0x402d01f8] OM - Memory_getBufferPhysicalAddress> return (0x0)
    @0x000b82fd:[T:0x402d01f8] CV - VISA_freeMsg(0x39fd8, 0x41478c80): Freeing message with messageId=0x0002003c
    @0x000b8383:[T:0x402d01f8] ti.sdo.ce.video1.VIDENC1 - VIDENC1_control> Exit (handle=0x39fd8, retVal=0xffffffff)

     

    It seems algorithm created successfully, but when calling VIDENC1_control, the Message Len is passed wrongly. Anyone have some ideas ? Thanks .

  • 0 in reply to Ning Wang10298
    TI__Mastermind 37340 points

    This is likely a problem in the number and size of pools CMEM has available for you to use; this information is typically specified in the loadmodules.sh script.  Are you changing the resolution od the encode demo at all?

    Additionally, just as a cautinary measure, I would refer to the codec release notes (should be included with your codec bundle request) and make sure that the correct version of the software components (such as CMEM) are being used with this codec.

  • 0 in reply to Ning Wang10298
    TI__Genius 17205 points

    The Memory_getBufferPhysicalAddress() call is being made inside the VIDENC1_control() call as it tries to convert an ARM-side virtual address to a DSP-accessible, physical address.  I think the only buffer provided to VIDENC1_control() is the VIDENC1_Status.data buffer.

    Are you sure the app is initializing that .data field correctly?  Note that if the control cmd being called (id=1 indicates it's XDM_SETPARAMS) doesn't utilize the .data field, the app _must_ initialize .data.buf ptr to NULL.  Seems like it may just be an uninitialized VIDENC1_Status.data field(?).

    Chris

  • 0 in reply to Chris Ring
    Intellectual 395 points

    Thanks Guys,

    Exactly, After setting the status.data.buf = NULL, the CEME error vanishes, and the encoder codec could run smoothly.

    Reagrds

    Wang Ning