> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.stereolabs.com/docs/development/zed-sdk/modules/camera/frame-rate-and-latency/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.stereolabs.com/_mcp/server.

# Frame Rate and Latency

The **grab rate**, set with the `camera_fps` parameter, is the frame rate at which the camera captures images. The available values depend on the camera model and on the selected resolution, and the grab rate directly affects three aspects of your application:

* **Latency**: the capture pipeline has a fixed latency measured in frames, so a higher frame rate reduces the time between the moment a scene is captured and the moment your application receives the image.
* **Image quality**: the exposure time cannot exceed the frame period. A higher frame rate allows shorter exposure times, which reduce motion blur on fast-moving scenes.
* **Computation load**: by default, the ZED SDK processes every captured frame, so a higher frame rate increases the CPU and GPU load of the host.

This page explains how to select the grab rate for your camera model, and how to combine the highest frame rate with the `grab_compute_capping_fps` parameter to get the lowest latency without overloading the host.

## Available frame rates by camera model

The available frame rates depend on the camera model and on the video mode:

#### ZED 2i, ZED 2, ZED Mini

| Video mode | Resolution (per sensor) | Frame rates (fps) |
| ---------- | ----------------------- | ----------------- |
| `HD2K`     | 2208x1242               | 15                |
| `HD1080`   | 1920x1080               | 30, 15            |
| `HD720`    | 1280x720                | 60, 30, 15        |
| `VGA`      | 672x376                 | 100, 60, 30, 15   |

#### ZED X, ZED X Mini, ZED X Nano

| Video mode | Resolution (per sensor) | Frame rates (fps) |
| ---------- | ----------------------- | ----------------- |
| `HD1200`   | 1920x1200               | 60, 30, 15        |
| `HD1080`   | 1920x1080               | 60, 30, 15        |
| `SVGA`     | 960x600                 | 120, 60, 30, 15   |

#### ZED X One GS, ZED X One S, ZED X One Core

| Video mode | Resolution | Frame rates (fps) |
| ---------- | ---------- | ----------------- |
| `HD1200`   | 1920x1200  | 60, 30, 15        |
| `HD1080`   | 1920x1080  | 60, 30, 15        |
| `SVGA`     | 960x600    | 120, 60, 30, 15   |

#### ZED X One 4K

| Video mode | Resolution | Frame rates (fps) |
| ---------- | ---------- | ----------------- |
| `4K`       | 3840x2160  | 15                |
| `QHDPLUS`  | 3200x1800  | 15                |
| `HD1200`   | 1920x1200  | 60, 30, 15        |
| `HD1080`   | 1920x1080  | 60, 30, 15        |

A virtual stereo camera built with two ZED X One cameras uses the frame rates of the ZED X One model it is made of.

## Set the grab rate

Select the resolution and the frame rate with the [`camera_resolution`](https://www.stereolabs.com/docs/api/structsl_1_1InitParameters.html#a760124c608fefd930b428910a52d929c) and [`camera_fps`](https://www.stereolabs.com/docs/api/structsl_1_1InitParameters.html#a8aebd3c5eea7c24cfa15a96cbb2ec8aa) initialization parameters, before opening the camera:

**`C++`**

```cpp C++
sl::Camera zed;

sl::InitParameters init_params;
init_params.camera_resolution = sl::RESOLUTION::HD1200;
init_params.camera_fps = 60;

sl::ERROR_CODE err = zed.open(init_params);
if (err != sl::ERROR_CODE::SUCCESS)
    exit(-1);
```

**`Python`**

```python Python
zed = sl.Camera()

init_params = sl.InitParameters()
init_params.camera_resolution = sl.RESOLUTION.HD1200
init_params.camera_fps = 60

err = zed.open(init_params)
if err != sl.ERROR_CODE.SUCCESS:
    exit(-1)
```

**`C#`**

```csharp C#
sl.Camera zed = new sl.Camera(0);

sl.InitParameters init_parameters = new sl.InitParameters();
init_parameters.resolution = sl.RESOLUTION.HD1200;
init_parameters.cameraFPS = 60;

sl.ERROR_CODE err = zed.Open(ref init_parameters);
if (err != sl.ERROR_CODE.SUCCESS)
    Environment.Exit(-1);
```

Keep in mind the following rules:

* If `camera_fps` is set to `0`, the default value, the ZED SDK uses the **highest frame rate** available for the selected resolution.
* If the requested frame rate is not available for the selected resolution, the ZED SDK uses the **closest available** frame rate.
* If `camera_resolution` is left at `AUTO`, the default value, the ZED SDK selects `HD1200` for the ZED X and ZED X Mini, and `HD720` for the other cameras.
* The resolution and the frame rate cannot be changed while the camera is open. Close and reopen the camera to change them.

To check the frame rate actually reached by your application, call [`getCurrentFPS()`](https://www.stereolabs.com/docs/api/classsl_1_1Camera.html#acbe60f3791ed7a9c31d2ab4da942f16c) (`get_current_fps()` in Python) while grabbing. It returns the rate at which `grab()` succeeds, computed from the camera timestamps of two consecutive successful calls.

## Host limits on the grab rate

The frame rate that your system can sustain can be lower than the maximum frame rate of the camera:

* **USB cameras**: the USB 3.0 bandwidth of a controller is shared by all the cameras connected to it. When the bandwidth is exceeded, corrupted frames appear and cameras can disconnect.
* **GMSL2 cameras**: each camera uses a dedicated link of the [ZED Link capture card](/docs/products/embedded/zed-link-capture-card/gmsl2) or of the ZED Box, but the number of cameras, the resolutions, and the frame rates are limited by the capture card and by the Jetson™ module.
* **Computation**: if the processing of each frame (depth, positional tracking, object detection, and so on) takes longer than the frame period, `grab()` runs slower than `camera_fps`.

The [Multi-Camera](/docs/development/zed-sdk/modules/camera/multi-camera) page gives hardware recommendations for USB and GMSL2 setups.

## Minimize the glass-to-glass latency

The glass-to-glass latency is the time between the moment a scene is captured by the camera sensor and the moment the corresponding image is displayed or used by your application. The part introduced by the camera and the ZED SDK capture pipeline is fixed when measured in frames:

* about **2 to 3 frames** for GMSL2 cameras,
* about **3 to 4 frames** for USB cameras.

This latency is therefore proportional to the frame period: **the higher the grab rate, the lower the latency**. To minimize it, set `camera_fps` to the **highest frame rate offered by the selected resolution** that your host can sustain, as described in [Host limits on the grab rate](#host-limits-on-the-grab-rate). If latency matters more than image resolution, also consider a lower resolution with a higher maximum frame rate, for example `SVGA` at 120 fps on a ZED X.

The following table gives the expected latency of the grab operation at the highest frame rate of each video mode:

| Camera model                                                          | Video mode         | Highest frame rate | Expected latency |
| --------------------------------------------------------------------- | ------------------ | ------------------ | ---------------- |
| ZED 2i, ZED 2, ZED Mini                                               | `VGA`              | 100 fps            | \~30 to 40 ms    |
| ZED 2i, ZED 2, ZED Mini                                               | `HD720`            | 60 fps             | \~50 to 67 ms    |
| ZED 2i, ZED 2, ZED Mini                                               | `HD1080`           | 30 fps             | \~100 to 133 ms  |
| ZED 2i, ZED 2, ZED Mini                                               | `HD2K`             | 15 fps             | \~200 to 267 ms  |
| ZED X, ZED X Mini, ZED X Nano ZED X One GS, ZED X One S               | `SVGA`             | 120 fps            | \~17 to 25 ms    |
| ZED X, ZED X Mini, ZED X Nano ZED X One GS, ZED X One S, ZED X One 4K | `HD1200`, `HD1080` | 60 fps             | \~33 to 50 ms    |
| ZED X One 4K                                                          | `4K`, `QHDPLUS`    | 15 fps             | \~133 to 200 ms  |

> **Note**
>
> These values refer to the **pure grab operation**, that is, the time needed to capture a frame and make it available through `grab()`. The processing performed by the ZED SDK on each frame, such as image rectification, depth computation, positional tracking, or object detection, adds its own time, which depends on the enabled modules and on the processing power of the host. On a less powerful host, or with heavier settings, the actual latency can therefore be noticeably higher than the values in the table.
>
> The glass-to-glass latency of your system also includes the processing time of your application and, if the images are displayed, the latency of the display pipeline.

> **Tip**
>
> A higher frame rate is also useful when the exposure is controlled manually: since the exposure time is expressed as a percentage of the frame period, a higher frame rate allows shorter exposure times and reduces motion blur.

## Reduce the computation load with grab\_compute\_capping\_fps

By default, running the camera at its highest frame rate also forces the ZED SDK to process every frame at that rate, which maximizes the CPU and GPU load. If your application does not need to process all the frames, or if the host cannot sustain this load, use the [`grab_compute_capping_fps`](https://www.stereolabs.com/docs/api/structsl_1_1InitParameters.html#a967f605a8580b99d0a6c3e9ab11b0578) initialization parameter.

`grab_compute_capping_fps` sets an **upper limit to the processing rate** of `grab()`, independently of the capture frame rate:

* The camera keeps capturing at `camera_fps`, so the capture pipeline latency stays as low as the camera frame rate allows.
* `grab()` always returns the **latest available image**, so processing at a lower rate does not make the images older: each processed image is the most recent one captured.
* The ZED SDK modules (image and depth retrieval, positional tracking, object detection, body tracking, and so on) run at most at the capping rate, which reduces the CPU and GPU load.

Unlike `camera_fps`, the capping value is not limited to the fixed frame rates of the camera: you can set any strictly positive value lower than `camera_fps`, for example `25.0`. Set it to `0` to disable the capping, which is the default behavior.

For example, to capture at 120 fps with a ZED X in `SVGA` mode for the lowest latency, while processing at most 30 frames per second:

**`C++`**

```cpp C++
sl::InitParameters init_params;
init_params.camera_resolution = sl::RESOLUTION::SVGA;
init_params.camera_fps = 120;               // Highest frame rate: lowest capture latency
init_params.grab_compute_capping_fps = 30;  // Process at most 30 frames per second
```

**`Python`**

```python Python
init_params = sl.InitParameters()
init_params.camera_resolution = sl.RESOLUTION.SVGA
init_params.camera_fps = 120               # Highest frame rate: lowest capture latency
init_params.grab_compute_capping_fps = 30  # Process at most 30 frames per second
```

**`C#`**

```csharp C#
sl.InitParameters init_parameters = new sl.InitParameters();
init_parameters.resolution = sl.RESOLUTION.SVGA;
init_parameters.cameraFPS = 120;              // Highest frame rate: lowest capture latency
init_parameters.grabComputeCappingFPS = 30;   // Process at most 30 frames per second
```

> **Note**
>
> * `grab_compute_capping_fps` is an upper limit: it has no effect if the processing is already slower than the capping value.
> * It has no effect when reading an SVO file.

### Find the best capping value

The best value depends on the processing power of the host and on the configuration of your application: resolution, depth mode, and enabled modules. To find it:

1. Set `camera_fps` to the highest frame rate available for your resolution.
2. Set `grab_compute_capping_fps` to the processing rate required by your application.
3. Run your application with its full workload and monitor the grab rate with `getCurrentFPS()`, and the CPU and GPU load of the host.
4. If the grab rate stays steadily at the capping value and the host has resources left, you can increase the capping value. If the grab rate cannot reach the capping value, the host cannot sustain this processing rate: decrease the capping value, or reduce the workload, for example with a lighter depth mode.

### Tune the power mode of a ZED Box

On a ZED Box Orin or a ZED Box Mini, the power mode of the NVIDIA® Jetson™ module sets the number of active CPU cores and the maximum CPU and GPU frequencies, and therefore the processing rate that the host can sustain. Once your capping value is defined, you can tune the power mode to balance processing frequency and power consumption:

* If the grab rate cannot reach the capping value, select a higher power mode to increase the processing power of the module, within the limits of your power supply.
* If the grab rate stays steadily at the capping value, try lower power modes and keep the lowest one that still sustains the required grab rate. This minimizes the power consumption and the heat of the host.

The available power modes and how to change them are described in the Power Modes guides of the [ZED Box Orin](/docs/products/embedded/zed-box-orin/power-modes) and of the [ZED Box Mini](/docs/products/embedded/zed-box-mini/power-modes).

> **Tip**
>
> With the ZED ROS 2 Wrapper, the same behavior is available through the `general.grab_frame_rate` and `general.grab_compute_capping_fps` parameters. See [Stereo Node Frequency Tuning](/docs/integrations/ros-2/node-frequency-tuning).

> Set the camera grab rate and minimize the glass-to-glass latency