Summary
We are experiencing consistent frame drops at HD1080@30fps on a ZED 2i. Every dropped frame manifests as an inter-frame gap of exactly 66–67ms (precisely 2× the 33.3ms sensor period), meaning one frame is missed each time. This occurs approximately 20 times per 15 seconds, resulting in an effective average of ~28.5fps instead of 30fps.
Critically, the drops occur even with a bare grab() loop — no recording, no depth, no tracking, no retrieve, no other SDK features enabled. This rules out all application-level causes and points to an SDK or firmware-level issue specific to HD1080 resolution.
HD720@30 and HD720@60 are completely clean (zero drops).
System
| Component | Version |
|---|---|
| Camera | ZED 2i (S/N 37864302, FW 1523) |
| ZED SDK | 5.2.2 |
| OS | Ubuntu 24.04.4 LTS, kernel 6.17.0-19-generic |
| GPU | NVIDIA GeForce RTX 5060 Laptop GPU (Blackwell) |
| NVIDIA Driver | 580.126.09 |
| CUDA | 13.0 |
| USB | Intel Raptor Lake USB 3.2 Gen 2x2 xHCI — camera on dedicated SuperSpeed bus at 5Gbps |
| Python | 3.12 (pyzed) |
| Power | AC power, CPU governor = `performance` |
Diagnostic methodology
We wrote a minimal Python script that isolates each variable independently. Each test:
- Opens the camera with
DEPTH_MODE.NONE,camera_disable_self_calib=True,enable_image_enhancement=False - Warms up for 90 frames (~3 seconds)
- Runs a tight
whileloop calling onlycam.grab(rt)for 15 seconds - Measures
time.monotonic()between eachgrab()return - Counts frames with inter-frame gap > 40ms
No other processes access the camera. No other significant USB devices are connected (tested with and without peripherals — same result).
Results
| # | Test Configuration | FPS | Avg gap | Max gap | Drops (>40ms) |
|---|---|---|---|---|---|
| 1 | Bare grab() — no recording | 28.5 | 35.2ms | 99ms | 21 |
| 2 | H264 recording | 28.5 | 35.1ms | 69ms | 21 |
| 3 | H265 recording | 28.6 | 35.0ms | 70ms | 20 |
| 4 | LOSSLESS recording | 28.2 | 35.5ms | 135ms | 22 |
| 5 | H264_LOSSLESS recording | 29.0 | 34.5ms | 67ms | 14 |
| 6 | H265_LOSSLESS recording | 29.2 | 34.3ms | 70ms | 11 |
| 7 | H264 + retrieve_image every frame | 28.0 | 35.8ms | 101ms | 27 |
| 8 | H264 + retrieve_image every 10th | 28.8 | 34.8ms | 100ms | 16 |
| 9 | H264 + positional tracking | 27.1 | 36.9ms | 99ms | 41 |
| 10 | H264 + GC disabled | 28.5 | 35.1ms | 100ms | 20 |
| 11 | H264 + image_enhance=ON | 27.7 | 36.1ms | 70ms | 33 |
| 12 | HD720@30 + H264 | 30.0 | 33.3ms | 37ms | 0 |
| 13 | HD720@60 + H264 | 60.0 | 16.7ms | 18ms | 0 |
| 14 | HD1080@15 + H264 | 14.9 | 67.0ms | 71ms | 224 (every frame) |
Key observations
- Test 1 vs Tests 12/13: Bare
grab()at 1080p drops 21 frames, while 720p@30 and 720p@60 (with recording!) drop zero. This proves the issue is resolution-specific, not encoding or application related. - Every drop is exactly 66–67ms: The gaps are perfectly quantized at 2× the frame period. This is not random jitter — it indicates a periodic internal buffer miss or scheduling conflict within the SDK’s 1080p frame delivery pipeline.
- 720p@60 pushes similar pixel throughput (110M pixels/s) as 1080p@30 (124M pixels/s), yet 720p@60 is flawless. This suggests the issue is not raw USB bandwidth but rather something specific to 1080p frame geometry or ISP pipeline timing.
- HD1080@15fps is catastrophic (test 14): Every single frame has a 67ms gap, meaning the SDK appears to be internally running at 30fps and delivering every other frame. This mode seems fundamentally broken.
- Compression mode has a secondary effect: With the baseline already dropping ~20 frames, NVENC encoding adds some additional load (H264/H265 standard are ~same as baseline, while H264_LOSSLESS and H265_LOSSLESS are slightly better).
- This pattern is consistent with the periodic drops reported in Consistently Spaced Dropped Frames using C++ SDK, which was reportedly fixed in SDK 4.2 but appears to have regressed.
Minimal reproduction script
import time
import pyzed.sl as sl
cam = sl.Camera()
init = sl.InitParameters()
init.camera_resolution = sl.RESOLUTION.HD1080
init.camera_fps = 30
init.depth_mode = sl.DEPTH_MODE.NONE
init.camera_disable_self_calib = True
init.enable_image_enhancement = False
err = cam.open(init)
assert err == sl.ERROR_CODE.SUCCESS, f"Camera open failed: {err}"
rt = sl.RuntimeParameters()
# Warmup
for _ in range(90):
cam.grab(rt)
gaps = []
prev = time.monotonic()
for _ in range(450): # ~15 seconds at 30fps
cam.grab(rt)
now = time.monotonic()
gaps.append((now - prev) * 1000.0)
prev = now
cam.close()
violations = [g for g in gaps if g > 40.0]
print(f"Frames: {len(gaps)}")
print(f"Avg gap: {sum(gaps)/len(gaps):.1f}ms")
print(f"Max gap: {max(gaps):.1f}ms")
print(f"Drops >40ms: {len(violations)}")
if violations:
print(f"Drop values: {\[f'{v:.0f}ms' *for* v *in* violations\[:20\]\]}")
\\\
## Frame timing graphs
We generated per-test frame timing graphs showing the exact pattern. The 1080p tests all show periodic spikes to ~67ms, while the 720p tests show a flat line. We can share these if helpful.
## Questions
1. Is there a known issue with HD1080 frame delivery timing on ZED 2i with SDK 5.2.2, specifically on Blackwell-architecture GPUs (RTX 5060)?
2. Could the USB/ISP pipeline for 1080p stereo have a scheduling issue that causes periodic single-frame misses?
3. Is there a firmware update for the ZED 2i (currently FW 1523) that might address this?
4. Are there any SDK init parameters or environment variables that could improve 1080p frame delivery consistency?
Thank you for looking into this. We are happy to run additional diagnostics or provide the full timing dataset.