refactor(deviceio): make FrameMetadataTrackerOak single-stream - #875
Conversation
📝 WalkthroughWalkthroughOAK metadata tracking now creates one Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
Comment |
FrameMetadataTrackerOak was the last schema-based tracker that did not fit the generated passthrough template from #853: it held N SchemaTrackers, one per OAK camera stream, while every other tracker is a 1:1 map between tracker and tensor collection. Narrow it to one stream per instance and create one tracker per stream instead, so its facade, base interface and live impl now match the generated in/ shape exactly, and its constructor matches every sibling tracker's plain collection_id. Breaking: the ctor takes a collection id ("oak_camera/Color") instead of a prefix plus stream list, and get_stream_data/stream_count are gone in favour of get_data. MCAP layout changes with it -- each tracker records under its own base name to "oak" and "oak_tracked" rather than one tracker writing a channel per stream name, so McapRecordingConfig now takes N entries and readers keyed on "<base>/Color" need updating. The two recording channels are deliberate: the generated live template writes every sample to channel 0 and the last sample per update to channel 1, and the plugin pushes from the camera callback independently of the host update rate, so samples do accumulate between updates. Refs #868. Signed-off-by: Jiwen Cai <jiwenc@nvidia.com>
1b737b5 to
76dcead
Compare
|
Tested with test_oak_camera.py with device and confirmed the mcap is able to be written. Each tracker represents one stream and has both oak and oak_tracked channels written. |
|
@nv-jakob I hope this will unblock you to run the template refactor with the OAK-D stuff as well |
Description
FrameMetadataTrackerOakheld NSchemaTrackers, one per OAK stream, while every other tracker is 1:1 with a tensor collection — the one thing blocking it from #853's generated template. Narrowed to one stream per instance; create one tracker per stream. Supersedes #874.The ctor takes a plain
collection_id("oak_camera/Color") rather than the(prefix, stream)in @shaosu-nvidia's comment: that pair is the generated template's exact signature, and every sibling tracker already takes a barecollection_id.Breaking.
get_stream_data/stream_count→get_data. Each tracker records under its own MCAP base name tooak/oak_trackedrather than one tracker writing a channel per stream, soMcapRecordingConfigtakes N entries and readers keyed on<base>/Colorneed updating. Two channels because the generated live template hardcodes reader indices0, 1.Out of scope. No replay impl — OAK never had one and codegen emits it. Manifest migration (last task of #868) is blocked on #853.
Refs #868
Type of change
Testing
Built clean with
cmake --preset py3.12on Linux aarch64 (Orin);ctest -LE "gpu|window"passes 233/233 (the 4 failures in a full run aregpu/window-labelled viz tests, untouched here). Smoke-tested the wheel's new API surface.No new automated tests: the existing OAK tests cover the schema, not the tracker, which needs a live OpenXR runtime plus hardware.
examples/oxr/python/test_oak_camera.py --mode schema-pusheris updated but not yet run on an OAK-D.Checklist
SKIP=check-copyright-year pre-commit run --all-filesgit commit -s) per the DCO