MCAP Format Registry
This document describes well-known values for MCAP files.
Compression formats
The Chunk compression field may contain the following options:
- lz4: an algorithm that prioritizes compression/decompression speed over compression ratio.
- zstd: an algorithm with a tunable compression ratio/speed tradeoff.
Message encodings
The Channel message_encoding field describes the encoding for all messages within a channel. This field is mandatory.
ros1
message_encoding:ros1
cdr
message_encoding:cdr(used in ROS 2)
protobuf
message_encoding:protobuf
flatbuffer
message_encoding:flatbuffer
cbor
message_encoding:cbor
json
message_encoding:json
Schema encodings
The Schema encoding field describes the encoding of a Channel's schema. Typically, this is related to the Channel's message_encoding, but they are separate concepts (e.g. there are multiple schema languages for json).
This field is required for some message encodings (e.g. protobuf) and optional for others (e.g. json).
(empty string)
Schema encoding may only be omitted for self-describing message encodings such as json.
name: May contain any valueencoding: (empty string)data: Must be empty (0 bytes)
protobuf
name: Fully qualified name to the message within the descriptor set. For example, in a proto file containingpackage foo.bar; message Baz {}the fully qualified message name isfoo.bar.Baz.encoding:protobufdata: A binary FileDescriptorSet as produced byprotoc --descriptor_set_out.
flatbuffer
name: Fully qualified name corresponding to a name in the reflection Object table. For example in a schema containingnamespace foo; table Bar {}the fully qualified name isfoo.Bar.encoding:flatbufferdata: A reflection.Schema flatbuffer describing the parsed schema encoded as a binary flatbuffer. This can be generated by runningflatc -b --schemaon the fbs file.
ros1msg
name: A valid package resource name, e.g.sensor_msgs/PointCloud2.encoding:ros1msgdata: Delimited concatenated ROS1 .msg files.
ros1msg Data Format
the data field contains the concatenated .msg file content that is sent in the ROS subscription connection header for this message type.
The top-level message definition is present first, with no delimiter. All dependent .msg definitions are preceded by a two-line delimiter:
- One line containing exactly 80
=characters - One line containing
MSG: <package resource name>for that type. The space betweenMSG:and the package resource name is mandatory. The package resource name does not include a file extension.
This format can be reproduced using gendeps --cat.
ros2msg
name: A valid package resource name, e.g.sensor_msgs/msg/PointCloud2.encoding:ros2msgdata: Delimited concatenated ROS2 .msg files
ros2msg Data Format
The .msg definition is stored alongside its dependencies in the same format as ros1msg.
ros2idl
name: A valid package resource name, e.g.sensor_msgs/msg/PointCloud2encoding:ros2idldata: Delimited concatenated ROS2 .idl files
ros2idl Data Format
The IDL definition of the type specified by name along with all dependent types are stored together. The IDL definitions can be stored in any order. Every definition is preceded by a two-line delimiter:
- a line containing exactly 80
=characters, then - A line containing only
IDL: <package resource name>for that definition. The space betweenIDL:and the package resource name is mandatory. The package resource name does not include a file extension.
omgidl
The omgidl schema encoding stores OMG IDL definitions for (X)CDR-encoded messages.
name: The globally-scoped name of the message type, eg.top_level_module::my_module::MyTypeencoding:omgidldata: valid OMG IDL definition file contents with a definition for the message type and all referenced types.
Producing schema.data for the omgidl schema encoding
Most commonly, IDL definitions for separate types are stored in separate files, and use C++ preprocessor #include statements to include definitions for types referenced in that definition.
For the omgidl schema encoding, the data field needs to contain all of those definitions. In
other words, the data field should read as a single source file containing definitions for the
message type and all referenced types.
One way to produce this is to use a C++ compiler to resolve those #include directives:
# Run from the root of your IDL definition tree, or use additional `-I` arguments to indicate your
# full include path to the compiler.
# The `gcc` output may contain debugging lines such as "# 1 "top_level_module/my_module/MyType.idl",
# the grep command here is intended to filter those out.
$ gcc -E -I. top_level_module/my_module/MyType.idl | grep -v "^# \d" > all_definitions.idl
For the following files:
#include "top_level_module/other_module/OtherType.idl"
module top_level_module {
module my_module {
struct MyType {
top_level_module::other_module::OtherType val;
}
}
}
module top_level_module {
module other_module {
struct OtherType {
float val;
}
}
}
This should produce:
module top_level_module {
module other_module {
struct OtherType {
float val;
}
}
}
module top_level_module {
module my_module {
struct MyType {
top_level_module::other_module::OtherType val;
}
}
}
For this example, schema.name should be set to top_level_module::my_module::MyType.
jsonschema
name: May contain any valueencoding:jsonschemadata: JSON Schema
Profiles
ROS1
The ros1 profile describes how to create MCAP files for ROS 1.
Header
profile: MUST beros1
Channel
message_encoding: MUST beros1metadatakeys:callerid(optional, string)latching(optional, bool stringified as "true" or "false")
Schema
encoding: MUST beros1msg
ROS2
The ros2 profile describes how to create MCAP files for ROS 2.
Header
profile: MUST beros2
Channel
message_encoding: MUST becdrmetadata:offered_qos_profiles(required, string)
Schema
encoding: MUST be eitherros2msgorros2idl