[Version-Update-Request] MCAP 1.3.0 -> 2.0.2 ... to avoid embedded dependency leakage issues

[marc-medley]

what:

This request is for depthai-core include/3rdparty/mcap MCAP to be updated from version v1.3.0 to v2.0.2.

At this time, the depthai-core main branch and develop branch have MCAP_LIBRARY_VERSION "1.3.0". This can be verified by checking depthai-core include/3rdparty/mcap/types.hpp:

• develop branch include/3rdparty/mcap/types.hpp
• main branch include/3rdparty/mcap/types.hpp

why:

1. The depthai-core embedded mcap 1.3.0 was found to leak into a CMake project which is otherwise expecting (and configured for) mcap 2.0.2. This leakage scenario resulted in run-time app crashes with segment fault core dumps.

2. The MCAP 2.0.2 version update request resolves a long list of issues as shown in the MCAP release history:

• v2.0.2
• v2.0.1
• v1.4.2
• v1.4.1
• v1.3.1

how:

This MCAP 2.0.2 version update is expected to be a drop-in replacement from foxglove/mcap cpp/mcap/include/mcap to:

• develop branch include/3rdparty/mcap
• main branch include/3rdparty/mcap

[moratom]

Thanks for the suggestion @marc-medley.
Do you maybe know if they maintained backwards compatibilty for the recorded data?

[marc-medley]

@moratom yes, "backwards compatibilty" of recorded data is retained since the major MCAP file content version itself remains at MCAP0.

Expanded details …

The MCAP file format version numbering ↗︎ is separate (independent) from the versioning of the language APIs ↗︎. Note the disparate release versioning relative to each language API ↗︎, e.g. releases/rust/v0.23.1 vs releases/cpp/v2.0.2.

MCAP Container Specification ↗︎

Magic

An MCAP file must begin and end with the following magic bytes:

0x89, M, C, A, P, 0x30, \r, \n

The byte following "MCAP" is the major version byte. 0x30 is the ASCII character 0. Any changes to this specification document (i.e. adding fields to records, introducing new records) will be binary backward-compatible within the major version.

MCAP Test Sample Files

The screenshots indicate that the libmcap 2.0.2 and libmcap 1.4.1 both used the same major version MCAP0.

[moratom]

Thanks for expanding @marc-medley - in this case we're fine updating, since the API of MCAP itself is not part of our public interface.

Have you by any chance done this on your side and would be willing to open a PR?