• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 97 subscribers
  • Views 239 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.

H.264 BP Encode v1.2 on DM6446 SPRS314D - August 2007

MRI
Expert 1130 points

I'm trying to determine the latency of this encoder. I don't understand how to translate the performance statistic numbers in Table 2 and the Encoding Times in Figure 1 to a latency number in seconds per frame.  Why is Performance Statistic Table 2 in Megacycle per second? How do I calculate the encoder latency using the Performance Statistic?

I use Figure 1, the max encodint time is about 25 megacycles. Would that mean the max latency is 25 x 10e6 / 594 x 10e6 = 42.1 msec?? Doesn't that exceed the 33.33 msec frame period at 30 fps?? It doesn't make sense.

  • 0
    TI__Mastermind 41665 points

    MRI said:
    I'm trying to determine the latency of this encoder. I don't understand how to translate the performance statistic numbers in Table 2 and the Encoding Times in Figure 1 to a latency number in seconds per frame. 

    The latency induced by the encoder itself is given outright in figure 1, though there may be additional system latency depending on where the encoded frame is going, and where the uncompressed frame came from so it is not so easy to define a end to end latency as that will be system specific.

    MRI said:
    Why is Performance Statistic Table 2 in Megacycle per second?

    The performance is being measured in terms of how much of the DSP bandwidth is being used to perform the decoding, for example on average with Tennis.yuv in the high quality preset configuration the encoder was using about 553MHz of DSP bandwidth.

    MRI said:
    How do I calculate the encoder latency using the Performance Statistic?

    Since the latency varies from frame to frame you cannot calculate the exact latency of every frame, though you can calculate the average frame encoding time. Since we are using 533MHz out of 594MHz of DSP bandwidth  we know that the DSP is spending most of its time trying to encode this video, but since we are not saturating the DSP we know there is some headroom so on average the frame encoding time is slightly less than the actual rate they are coming in (at 30fps there is a frame every 33.3mS). To figure the average frame encoding time (latency) we could take 533MHz / 594MHz = 89.73% DSP loading, which should translate to an average encoding time of 33.3mS * .8973 = 29.88mS.

    MRI said:
    I use Figure 1, the max encodint time is about 25 megacycles. Would that mean the max latency is 25 x 10e6 / 594 x 10e6 = 42.1 msec?? Doesn't that exceed the 33.33 msec frame period at 30 fps?? It doesn't make sense.

    It does break the real time deadline, this is also reflected in the table 2 figures, which show the tennis.yuv encode with high quality preset peak DSP bandwidth usage being greater than the DSP frequency (634MHz DSP bandwidth on a 594MHz DSP means a frame will be dropped), though as of yet I am unable to reconcile that the graph seems to show spikes of higher peak bandwidth usage than the table 2 lets on, I suppose the calculations or measurement may have been done a bit differently.