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

decode_display OpenMAX Demo High ARM Utilisation

_Ralph_
Guru 10685 points

I'm concerned by the decode_display demo's high CPU utilisation. At 1080p60 we are talking about 30% utilisation per decode stream (as shown by "top")!

85% of the program's time is spent in the "Decode_DoChunking" function which finds out how big the next frame is. I have read the OpenMAX User Guide and see that TI's implementation of the VDEC component requires the start of the frame to coincide exactly with the start of the buffer passed to the component.

This is fair enough; however the hardware must be decoding the frame and also finding out how big the frame for itself so is there any way to get this information from the HDVICPs into the application? This would then eradicate that 85% of the time spent parsing the H264. This webpage mentions a "file-mode" but I have no documentation on implementing it or even if TI's OpenMAX implementation supports it.

This is a really important issue for us as at present it looks like we are going to have to use the DSP to parse the H264 frames just so the ARM has enough utlilisation to do anything else.

Thanks,

Ralph

  • 0
    TI__Expert 6535 points

    Ralph,

    Parser used in demo is not optimized version, It can be probably optimized to ~50 % of current cycles. Decoder can provide data that how much it consumed, so app can take ramaining data in next buffer and refill with more. But it will cause delays as app will have to wait for every frame, before it can give next frame, that's reason for using parser.

    Regards

    Vimal

  • 0 in reply to Vimal Jain
    Guru 10685 points

    Hi Vimal,

    Are there plans to release an optimised parsing block in a future release of decode_display?

    Surely the delay in sending back the information about the frame size from the decoder is small enough that it won't affect the decoding of the next frame? Is TI going to at least see if this works? It's a bit hard for me to have a go given that I have no source code for the HDVPSSs!

    Thanks,

    Ralph

  • 0 in reply to _Ralph_
    TI__Intellectual 2910 points

     

    _Ralph_ said:
    Surely the delay in sending back the information about the frame size from the decoder is small enough that it won't affect the decoding of the next frame? Is TI going to at least see if this works? It's a bit hard for me to have a go given that I have no source code for the HDVPSSs!

    The delay will hit us badly if we are pushing the HW to its maximum capabilities (say H.264 1080P60 decode on one HDVICP2, the HW here). It would be neccessary in such cases to keep the HW running with no downtime/delays with buffers reaching the HW. 

    To get source code access, please contact your local TI representatives. They will be able to get you access. Please let us know if you face difficulties with that.

     

    Archith