Get desktop application:
View/edit binary Protocol Buffers messages
Corresponds to `LogMsg::ArrowMsg`. Used to transmit actual data.
Used in: ,
The ID of the store that this message is for.
If the payload is a chunk, this is its ID. Otherwise empty.
Compression algorithm used.
Encoding of the payload.
Arrow-IPC encoded schema and chunk, compressed according to the `compression` field.
If true, this is guaranteed to be a chunk containing only static data.
Corresponds to `LogMsg::BlueprintActivationCommand`. Used for activating a blueprint once it has been fully transmitted, because showing a blueprint before it is fully transmitted can lead to a confusing user experience, or inconsistent results due to heuristics.
Used in:
The ID of the blueprint to activate.
Whether to make the blueprint active immediately.
Whether to make the blueprint the default.
Information about the Rust SDK that created the recording.
Version of the Rust compiler used to compile the SDK.
Version of LLVM used by the Rust compiler.
The encoding of the message payload.
Used in:
We don't know what encoding the payload is in.
The payload is encoded as Arrow-IPC.
A recording which came from a file.
Determines where the file came from.
Used in:
We don't know where the file came from.
The file came from the command line.
The file was served over HTTP.
The file was dragged into the viewer.
The file was opened using a file dialog.
The recording was produced using a data loader, such as when logging a mesh file.
There are 3 different `LogMsg`-related types that you will very often encounter: `re_log_types::LogMsg`, `re_protos::log_msg::v1alpha1::LogMsg` and `re_protos::log_msg::v1alpha1::log_msg::Msg`. Mixing them up is a common source of pain and confusion, so let's go over what each does: * `re_log_types::LogMsg` is the application-level type that we use all across the viewer codebase. It can be obtained by calling `to_application()` on one of the transport-level `LogMsg` types which, among many other things, will perform Chunk/Sorbet-level migrations. `re_log_types::LogMsg` isn't used in Redap, where everything is done at the transport-level, always. * `re_protos::log_msg::v1alpha1::LogMsg` is the transport-level definition of `LogMsg`. It is an artifact of how `oneof` works in Protobuf: all it does is carry a `re_protos::log_msg::v1alpha1::log_msg::Msg`. For that reason, it is never directly used, except by the legacy SDK comms protocol. * Finally, `re_protos::log_msg::v1alpha1::log_msg::Msg` is the real transport-level type that we care about. It is used all over the place when encoding and decoding RRD streams. TODO(#8631): Remove `LogMsg`
Used in: ,
A message that contains a new store info.
A message that contains an Arrow-IPC encoded message.
A message that contains a blueprint activation command.
Version of the Python SDK that created the recording.
This is the payload that is carried in messages of type `::End` in RRD streams. It keeps track of various useful information about the associated recording. During normal operations, there can only be a single `::End` message in an RRD stream, and therefore a single `RrdFooter`. It is possible to break that invariant by concatenating streams using external tools, e.g. by doing something like `cat *.rrd > all_my_recordings.rrd`. Passing that stream back through Rerun tools, e.g. `cat *.rrd | rerun rrd merge > all_my_recordings.rrd`, would once again guarantee that only one `::End` message is present though. I.e. that invariant holds as long as one stays within our ecosystem of tools. This is a transport-level type, the associated application-level type can be found in `re_log_encoding::RrdFooter`.
All the `RrdManifest`s that were found in this RRD stream. Each `RrdManifest` corresponds to one, and exactly one, recording. The order is unspecified.
This is the payload found in `RrdFooter`s. Each `RrdManifest` corresponds to one, and exactly one, RRD stream (i.e. recording). This restriction exists to make working with multiple RRD streams much simpler: due to the way the Rerun data model works, filtering rows of data from a manifest can have hard-to-predict second order effects on the schema of the stream as a whole. By keeping manifests for different recordings separate, we remove the need to filter per recording ID, greatly simplifying the process. This is a transport-level type, the associated application-level type can be found in `re_log_encoding::RrdManifest`.
Used in: ,
The recording ID that was used to identify the original recording. This is extracted from the `SetStoreInfo` message of the associated RRD stream.
The Sorbet schema of the associated RRD stream. ⚠️ This is the Sorbet schema of the recording being indexed by this manifest, *not* the schema of `Self::manifest`.
The SHA256 hash of the Sorbet schema of the associated RRD stream. This is always computed by sorting the fields of the schema by name first.
The complete manifest for the associated RRD stream. Each row in this dataframe describes a unique chunk (ID, offset, size, timeline & component stats, etc). This can be used to compute relevancy queries (latest-at, range, dataframe), without needing to load any of the actual data in memory.
Corresponds to `LogMsg::SetStoreInfo`. Used to identify a recording.
Used in:
A time-based UID that is used to determine how a `StoreInfo` fits in the global ordering of events.
The new store info.
Information about a recording or blueprint.
Used in:
User-chosen name of the application doing the logging. This is deprecated and kept for backward compatibility. TODO(#10730): turn that into `reserved` statement when removing backward compatibility
Unique ID of the recording.
Where the recording came from.
Version of the store crate.
The source of a recording or blueprint.
Used in:
Determines what is encoded in `extra`.
Store source payload. See `StoreSourceKind` for what exactly is encoded here.
A newtype for `StoreSource` payload. This exists to that we can implement conversions on the newtype for convenience.
Used in:
What kind of source a recording comes from.
Used in:
We don't know anything about the source of this recording. `extra` is unused.
The recording came from the C++ SDK. `extra` is unused.
The recording came from the Python SDK. `extra` is `PythonVersion`.
The recording came from the Rust SDK. `extra` is `CrateInfo`.
The recording came from a file. `extra` is `FileSource`.
The recording came from some action in the viewer. `extra` is unused.
The recording came from some other source. `extra` is a string.
Used in:
Crate version encoded using our custom scheme. See `CrateVersion` in `re_build_info`.