Title: ZED SDK 5.4.0 sequential SVO2 playback stops at 469 of 499 frames on files recorded by ZED SDK 5.2.3 — seek
playback reaches the missing tail
Environment
- Windows, ZED SDK / pyzed 5.4.0 (python bindings, sl.cp310-win_amd64.pyd wrapping sl_zed64.dll 5.4.0)
- Replaying a .svo2 file recorded by ZED SDK 5.2.3 (svo_header reports “ZED_SDK_version”:“5.2.3”, “version”:“2.0.5”)
- InitParameters.svo_real_time_mode = false, depth_mode = DEPTH_MODE.NONE, left view only
Symptom
- get_svo_number_of_frames() returns 499 (matches header / side_by_side channel message count).
- A pure sequential grab() loop returns END_OF_SVOFILE_REACHED after exactly 469 frames — the last 30 frames (indices
469–498) are never read sequentially. - The same 28-frame deficit appears across hundreds of different files (frame-validation confirms a constant −28 vs.
the authoritative frame count), at production scale. - Seek playback (set_svo_position(idx) then grab()) successfully decodes indices 469 → 497 (the tail frames exist and
are fully decodable), stopping only at index 498, which is corrupt/unreadable even via seek. - ZED SDK 5.0.0 (svo_count.exe from a 5.0.0 installation) replays the same file sequentially up to 497 frames — i.e.
an older SDK sequentially reads the whole file correctly.
Minimal repro (5.4.0, pyzed)
import pyzed.sl as sl
zed = sl.Camera()
ip = sl.InitParameters()
ip.set_from_svo_file(“Image_xxx.svo2”)
ip.svo_real_time_mode = False
ip.depth_mode = sl.DEPTH_MODE.NONE
zed.open(ip)
declared = zed.get_svo_number_of_frames() # → 499
n = 0
while n < declared:
if zed.grab() != sl.ERROR_CODE.SUCCESS:
break
n += 1
print(n) # → 469 (END_OF_SVOFILE_REACHED here)
Structural analysis of the file (MCAP container)
- Single MCAP container, 37 chunks, all uncompressed.
- Sequential replay decodes chunks 0–33 = 469 frames and stops at the first frame of chunk 34:
- chunk 34 → frames 469–481 (13)
- chunk 35 → frames 482–495 (14)
- chunk 36 → frames 496–498 (3)
- The tail frames are structurally identical to every earlier frame — uniform ~33.3 ms cadence, uniform ~38–50 KB
payloads, valid frame headers, no corruption/gaps.
Expected behavior
Sequential grab() should stream all frames up to get_svo_number_of_frames(), or at least the valid per-frame metadata
count (497 here), on files recorded by 5.2.x.
Actual behavior
Sequential playback truncates at 469 of 499; only seek playback reaches the recorded tail.
Workaround we are using
After sequential grab() returns END_OF_SVOFILE_REACHED below the declared count, call set_svo_position(n) and
continue grab() until the authoritative frame count — this recovers all decodable tail frames.
Questions
- Is early END_OF_SVOFILE_REACHED on sequential playback of 5.2.x-recorded SVO2 a known regression in ZED SDK
5.4.0’s SVO2 sequential reader? - Why does sequential streaming stop at the chunk 33→34 boundary while the seek path (message index) reads the same
chunks fine? - Roughly how many frames are expected to be “flushed but not sequentially readable” for a 5.2.x recorder at stop
time, and is there an SDK fix planned?