FPS value displayed in the Hailo tiling application

General Discussion
1

Hi everyone,

I have a question about the FPS value displayed in the Hailo tiling application (the one shown on the video stream when using the --show-fps option, with values like rendered, dropped, current, and average).

I would like to understand exactly what this FPS represents.

Specifically:

  1. Does this FPS include the full end-to-end pipeline latency, such as:

    • Raspberry Pi camera capture latency (sensor exposure + readout)

    • frame transfer to the host

    • preprocessing (resize / tiling / color conversion)

    • inference time on the Hailo device (HEF execution)

    • post-processing

    • rendering to the display

  2. Or does it only measure the rendering/output rate of the pipeline (i.e., how many frames reach the display sink per second)?

  3. Where exactly in the codebase is this FPS calculated?
    I looked at the tiling pipeline files but couldn’t find the precise location where the FPS counter is computed.
    Which .py file or component is responsible for calculating the current and average FPS that appear on the video overlay?

In short, I’m trying to understand whether the FPS shown by the tiling app reflects the true end-to-end performance of the system or just the display throughput.

Thanks in advance for any clarification.

2

Hi @Zara_Ai,

The FPS overlay shown with --show-fps is provided by GStreamer’s built-in fpsdisplaysink element, not by any custom Hailo code - so you won’t find a .py file with a manual FPS calculation. You might want to look at the DISPLAY_PIPELINE function in gstreamer_helper_pipelines.py, which is where fpsdisplaysink is configured with text-overlay={show_fps} signal-fps-measurements=true.
What it measures is the rate at which fully-processed frames arrive at the display sink, so it reflects the overall pipeline throughput rather than the latency of any single frame. In practice, because GStreamer is a push-based pipeline, if any stage (capture, preprocessing, inference, postprocessing) is a bottleneck, it will limit how many frames reach the sink and thus lower the displayed FPS - so it could be thought of as an indirect reflection of end-to-end performance, but it is specifically a throughput metric (frames per second reaching the output), not a per-frame latency metric. If you need to measure actual per-stage latency, you might try using GstShark tracers (such as proctime or interlatency ) which can give you processing time and latency breakdowns for individual pipeline elements.

Thanks,