Recordings

Recordings are the core abstraction for organizing data in Rerun.

A Recording is a semantic collection of data with an associated Recording ID (which is just another name for a UID). That's it.

Recordings are a logical abstraction, not a physical one: a recording is not confined to a specific file, or folder, or database, or whichever physical storage you might think of. Similarly, there is no such thing as "closing" a recording: as long as there exists or will exist a system somewhere that is capable of producing chunks of data, and tagging these chunks with the appropriate Recording ID, then that recording is effectively still growing. Whether that happens today, tomorrow, or in some distant future.

This design naturally allows for both the production and the storage of recordings to be horizontally distributed:

• Production can be handled by multiple producers that all log data to the same Recording ID, independently.
• Storage can be sharded over multiple independent files (or any other storage medium).

You can learn more about sharding in the dedicated documentation page.

In practice, most Rerun recordings are encoded in binary files with the .rrd extension by default. This is our basic storage solution for recordings, which is specifically designed for streaming use cases (i.e. .rrd files do not offer random-access to the data within). Note that blueprints are recordings too, and by convention are stored in binary .rbl files.

Application IDs application-ids

Rerun recordings have an extra piece of metadata associated with them in addition to their Recording ID: an Application ID. Application IDs are arbitrary user-defined strings.

When you initialize the Rerun logging SDK, you need to set an Application ID.

rr.init("my_custom_application_id")

The Rerun viewer will store your blueprint based on this Application ID.

This means that you can run your app and set up the viewer to your liking, and then when you run the app again the Rerun viewer will remember how you set up your Space Views etc. Different recordings (i.e. different Recording IDs) will share the same blueprint as long as they share the same Application ID.

Check out the API to learn more about SDK initialization:

• 🐍 Python
• 🦀 Rust
• 🌊 C++

Recording IDs in practice recording-ids-in-practice

Each time you start logging using Rerun, a random Recording ID is generated. For instance, each .rrd file will have a unique Recording ID.

This means you can have multiple recordings with different Recording IDs sharing the same application ID.

If you want to log from multiple processes and want all the log data to show up together in the viewer, you need to make sure all processes use the same Recording ID.