• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 99 subscribers
  • Views 673 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.

C6678 H.264 Encoder internalDataMemory array placement

Chris Johnson1
Expert 1715 points

Hello,

I am working with the H.264 encoder and the provided source for using it. I am trying to get around a memory limitation that is mostly due to the internalDataMemory array defined in alg_malloc.c which is using half of the available L2 memory. While only running on one core, I noticed that I can change the placement of the .intDataMem section to be in MSMCSRAM and saw no problems. When I instead move the section to DDR3, problems occur. It appears to only encode a few frames (3-4) then either hangs or errors out. I haven't had the chance to do much investigation yet to figure out what the exact problem is, but I figured the information so far was enough to warrant a question.

What limitations in the H.264 library or the provided example code would prevent the placement of this array into DDR3 memory?

Regards,
Chris
Signalogic, Inc.

  • 0
    Expert 1715 points

    Just a quick update on this. When that array is in DDR3, it looks like after encoding a few frames, the code gets stuck in the encode call to the library. 

    Another thing I discovered is that when the array is in MSMCSRAM, even though it appears to run fine, the output quality is very poor and there are a lot of artifacts in the video. It seems like this memory array needs to be in L2SRAM. 

    Why does this L2SRAM requirement exist, and is there any way around it?

    Regards,
    Chris

  • 0 in reply to Chris Johnson1
    Expert 1945 points

    Hi Chris,

    Almost all of the encoder internal memory allocations are done through .intDataMem pointer. Inside encoder this memory is used for DMA structure, bitstream buffer info, scratch buffers for different algorithms (including assembly level code) etc. Sharing or moving this region to DDR will make the data region written/read my multiple cores.

    Thanks and regards

    Sudheesh

  • 0 in reply to Sudheesh
    Expert 1715 points

    Sudheesh,

    My plan for moving it to DDR3 was to have a different array of the same size for each core and modify the alg_malloc.c file to use a given array based on DNUM. I am only using 1 core currently so I wouldn't expect having that section in a shared memory region to cause problems. 

    Should this be doable or are there other reasons for this section to be in L2 memory?

    Regards,
    Chris

  • 0 in reply to Chris Johnson1
    Expert 1945 points

    Chris,

    Internal memory allocations are protected across process calls through copying buffers from DDR -> L2 and L2-> DDR during alg activate, de activate calls and sync the data. Cache issues happens when this L2 buffer is moved over to DDR. If cache is disabled it looks fine. So it is not recommeded to keep this buffer other than L2.

    The main reason for moving some buffers to L2 is to meet performance. Significant performance drop can be there if you move buffers out of L2.

    If you have the full source code of H264HP encoder, it is possible to tryout moving some buffers out of L2 to meet your arrary requirement as well as performance requirements.

    Thanks and regards

    Sudheesh

  • 0 in reply to Sudheesh
    Expert 1715 points

    Got it. Thanks for the info, Sudheesh.

    Regards,
    Chris