Texas Instruments SPRAA56 appendix Measuring the Frame Rate

SPRAA56

The low-resolution CLK_getltime API is used instead of the high-resolution CLK_gethtime because the range of the latency is known to be on the order of one or more frame times, where a frame time is 33.33 ms in NTSC systems. The low-resolution timing measurement provided by CLK_getltime is more cycle efficient and is in milliseconds. Since the data is displayed in milliseconds, the lower-resolution time base results in a faster measurement, with sufficient accuracy for the latency benchmark.

The corresponding code in the video output task finishes the benchmark once the frame has propagated through the system:

if (!benchCapVid.captodisplay.done) { // benchVideoDisRta.captodisplay benchCapVid.captodisplay.latency

=CLK_getltime() - benchCapVid.captodisplay.latency;

//current time - last captured frame timestamp = latency

UTL_logDebug2("Latency = %d [ms], for frame %d ", benchCapVid.captodisplay.latency, benchCapVid.captodisplay.frameNum );

benchCapVid.captodisplay.done = 1;

}

Note that this measurement does not include the latency introduced by the capture and display drivers. Similar techniques could be applied, using the UTL or STS APIs, to measure the driver latency, however this would require modifying and rebuilding the driver, which is outside the scope of this application note. To measure the total input-to-output latency, add the driver latencies to the measured benchmark reported here.

4.4Measuring the Frame Rate

Frame rate is the rate, in frames per second or Hz, of the capture, processing, or display of video frames by the system. In video systems it is possible for the display frame rate to exceed the capture and/or processing frame rate, so it is often important to measure it separately for the capture, processing, and display stages in the data stream.

In this example application, the actual frame rate is measured at each stage, and user control of the frame rate is provided for the processing stage.

During periods of peak CPU loading, the processing rate of the DSP can fall below the display rate of the output device, resulting in dropped frames. Dropped frames are frames that were received during capture or decode but not displayed, or frames that were captured but not encoded. Frame dropping can occur when the CPU is overloaded by the processing required for real-time encoding or decoding.

The VPORT display driver from the DDK is written to handle this condition gracefully. If a new frame is not received from the application in time for the video port to display it, the device driver continues to show the previously displayed frame. With high-motion video, this condition can sometimes result in noticeable “jerkiness”. At other times, dropped frames can be difficult to detect or quantify, so a method of detecting dropped frames is useful during development, debugging, and demonstrations. A method for detecting dropped frames is implemented in this application using the UTL and CLK services.

The following code from the tskProcess function measures the number of dropped frames by subtracting the reference time from the actual time required to capture 30 or 25 frames. The reference time should be approximately 1 second for NTSC or PAL systems, respectively.

DSP/BIOS Real-Time Analysis (RTA) and Debugging Applied to a Video Application 13