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.

TMS320C6678: HEVC/H.265 Decoding Performance

Part Number: TMS320C6678

Hi,

Referring to table 2 in the document below:

http://software-dl.ti.com/dsps/dsps_public_sw/codecs/C6678/HEVC_D/latest/exports/HEVC_Decoder_C6678_DataSheet.pdf

Can you clarify if I need to divide the Mcycles by the clock frequency of 1250MHz to get the average frame decode latency? Or do we need to take into account the number of cores used in each configuration?

Configuration _006 is the closest to our use case and according to the table it takes ~600ms to decode a frame.

Why do the low delay cases have higher average Mcycle counts?

Video is 480 by 480, 30Hz, mono coming in over Ethernet. We decode the video, add overlays, and then display over an analog channel. No encoding is required at this time.

 

Thanks,

Jeramie

  • Hi Jeramie, the table shows Mega cycles per core. So in case of configuration _006, it means for decoding 720x480@60fps 1MB, IBB it takes average 864 MCycles and could be peaks of ~1000 MCycles.. so that roughly means you would have ~250 MCycles or room for other things, or as a safety bandwidth in case of more complex videos, or more complex HEVC streams..

    Could you please explain me how did you get to ~600ms to decode a frame?

    Your use case sounds simpler than configuration _006. It has less resolution, less fps, and only "Y" if I understood correctly. If so, this could be handle by one core.

    Hope this helps.

    thank you,
    Paula
  • Hi Paula,

    Thanks for your response. The thought on 600ms was configuration 006 shows an average of 864 Mcycles/sec. The clock is 1250Mhz so 864/1250 should be how much processing time is required to decode the frame.

    Regards,
    Jeramie