For ROS 2 recordings, the MCAP storage plugin’s writer options control chunking, compression and indexing inside the MCAP file. A ros2 bag convert configuration instead identifies input and output bags and can point to that separate writer configuration. Preserve both layers when reproducing a dataset; the .mcap filename alone does not identify how it was written.
Two recordings can contain the same topic names while differing in compression, indexes and the route used to produce them. That affects how a downstream reader accesses the data and what configuration must be recovered when the files are regenerated.
Chunk compression belongs to the writer
The MCAP plugin’s current writer documentation defines chunkSize as a target uncompressed payload size in bytes. It lists compression algorithms and levels, and notes that chunk-related compression settings are ignored when chunking is disabled.
This is a concrete reason to retain the complete writer options. Recording compression: Zstd without the chunking setting can misdescribe the actual path. The document also explains that, by default, a chunk that does not benefit from compression can be written uncompressed unless compression is forced.
The writer’s options include message indexes and summary sections as well. Omitting those structures changes access and summarization behavior; it should be a deliberate capture decision rather than an unexplained difference discovered by the training reader later.
| Layer | Example fields | What the record explains |
|---|---|---|
| Recorder selection | Topics, QoS and timing settings | Which messages could enter the recording |
| Storage identity | storage_id: mcap |
Which storage plugin writes the output |
| MCAP writer | Chunking, chunk size, compression, indexes | How messages are organized in the file |
| Conversion job | Output URI and writer-config reference | Which derived file was created from which input |
The rosbag2 recording guide covers the first layer. Storage options do not explain missing messages that never reached the recorder.
A conversion file can point to a writer file
The official MCAP ROS 2 guide shows ros2 bag convert with an output entry containing storage_id: mcap and storage_config_uri. The referenced file supplies MCAP compression options. The guide currently warns against placing compression_mode and compression_format directly in that conversion example because the resulting rosbag2 can be unplayable.
Treat that as a version-sensitive documented condition. Retain the exact rosbag2 and storage-plugin versions and verify the produced output with the intended reader. Do not infer support for a configuration combination from a similarly named setting in another compression layer.
A useful manifest links the original input hash, conversion configuration, referenced writer file and output hash. Include the paths as used by the job so a relative writer-config reference can be resolved later. The manifest describes the transformation; the output’s content checks establish what it produced.
Direct recording and later conversion have different prerequisites
The same guide distinguishes direct recording from conversion using the standalone mcap CLI. Its documented .db3 route reads embedded message definitions available in bags recorded with ROS 2 Iron and later. Older bags need the original ROS workspace for the documented ros2 bag convert route.
Before choosing a converter, inspect whether the required message definitions are available and which tool will supply them. An unknown custom type is a decoding problem to resolve, not a reason to label the topic empty.
Check the output through the consumer you intend to use
After a proposed conversion, compare required topics, message counts, timestamp ranges and representative decoded payloads with the input. Inspect indexed seeking or partial reads if the downstream workflow depends on them. A sequential scan and a random episode lookup exercise different access patterns.
The damaged-MCAP recovery article addresses a separate case: salvaging an interrupted file. Keep planned conversion records distinct from recovery records so a derived dataset retains its actual history.
The guide and captured Rolling plugin documentation were checked October 16, 2026. No bag was recorded, converted or replayed here. For a reproducible MCAP artifact, retain the writer configuration and the conversion job separately, then verify the resulting messages with the intended consumer.