• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 364 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.

Software Upgrade to Route Captured Data to Encoder through DMA?

Derek Richardson
Intellectual 610 points

Hello, I have a DM368 EVM rev G and I've been working on reducing the latency in the video pipeline.  Is there a software upgrade available to reduce the amount of latency between the capture driver and encoder?  I've been analyzing the encodedecode demo and there appears to be about 6 frames of latency between the capture driver and the encoder.  At 30fps, that's about 200ms of latency. 

Our FAE mentioned that in order to reduce the latency, one possible solution would be to re-route the captured data via direct route through DMA.  Is there a software upgrade available to accomplish this?

Thanks

Derek

  • 0
    TI__Mastermind 19985 points

    Hi,

    Marking this post as closed as we are tracking the same issue from you in the other thread

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/100/p/119061/423782.aspx#423782

    Derek Richardson said:

    Our FAE mentioned that in order to reduce the latency, one possible solution would be to re-route the captured data via direct route through DMA.  Is there a software upgrade available to accomplish this?

    BTW, i am not sure of the solution described in the above statement. The captured data is actually captured on DDR through a direct DMA in VPSS blocks. If you can get more information, we can try to understand this better.

    Regards,

    Anshuman

     

  • 0 in reply to Anshuman Saxena
    Intellectual 610 points

    Hi Anshuman, our FAE was suggesting possible solutions to reducing the latency.  This is what our FAE mentioned:

    "Take a look at the video streaming routes. If the data coming in from the camera port goes to ARM9 under Linux and then gets into DM368 codec through DSP Link and DSP Lib, you will need to re-route it to codec directly via DMA. Linux on ARM slows things down."

    I don't think the DM368 uses DSP Link, does it?

    As you mentioned, captured data is passed to DDR through direct DMA, so, I believe it's already doing what he was suggesting.

     

    Thanks

    Derek

  • 0 in reply to Derek Richardson
    TI__Mastermind 19985 points

    Hi Derek,

    Derek Richardson said:

    "Take a look at the video streaming routes. If the data coming in from the camera port goes to ARM9 under Linux and then gets into DM368 codec through DSP Link and DSP Lib, you will need to re-route it to codec directly via DMA. Linux on ARM slows things down."

    I don't think the DM368 uses DSP Link, does it?

    The above statement may be valid for DM6467 or DM6446 kind of devices. On DM368, we dont have any DSP and DSP Link layer is not used. The raw/YUV data is directly received on the DDR through dedicated DMAs in the VPSS and is passed to the H.264 encoder. The encoder internally uses the EDMA to get it into local buffers for processing. So in summary, there is no separate DMA needed for any data movement. Ofcourse, if you are trying to do any sort of memcpy() to pass the buffers, that can be optimized using EDMA.

    Regards,

    Anshuman

    PS: Please mark this post as verified, if you think it has answered your question. Thanks.