Overview

VRS is a file format optimized to record and playback streams of sensor data, such as images, audio, and other discrete sensors (IMU, temperature, etc.), that are stored in per-device streams of time-stamped records.

VRS was first created to record images and sensor data produced by early prototypes of the Meta Quest device, to develop the device’s positional tracking system known as Oculus Insight, Meta Quest 2's hand tracking, and more to come.

Project Aria records its data as VRS files.

Appropriate Use Cases

VRS is designed to record similar looking bundles of data produced repeatedly over a period of time, in time-stamped records.

Good Use Cases

VRS is very well suited to record and playback:

Data produced by the cameras and sensors of a Meta Quest device, including IMUs.

Data produced by the cameras and sensors of Project Aria Glasses, including positional tracking cameras, eye tracking cameras, barometer sensors, GPS and BT beacons, multi-channel audio.

Data produced in burst of activity, such as keyboard or mouse input data.

TCP/IP or USB packets.

Poor Use Cases

Even if VRS could be used to store pretty much any data, VRS is a poor choice to record anything without temporal information or data format regularity, such as:

Text documents.

Web pages.

Point cloud data.

3D models.

Single images with annotations, unless you bundle many images and annotations in a single VRS file.

info

While VRS is very effective at streaming very large amounts of data to disk, potentially to and from cloud storage, with real-time lossless compression, creating files potentially very large (typical VRS files range from 5 to 80 GB, but 1.5 TB VRS files exist), editing VRS files is not nearly as convenient, as the entire container typically needs to be rewritten.

Data Types and Data Conventions

VRS provides standardized methods to store images, audio, and discrete sensors data in compact and format evolution resilient records, so you can save data without having to worry too much about evolving requirements. But while VRS standardizes how to save common data types, VRS does not prescribe how to address specific use cases. Data format conventions are desirable, to enable teams working on identical or similar use cases to exchange data. However, such data format conventions are out of the scope of VRS.

Features Overview

• VRS files contain multiple streams of time-sorted records generated by a set of sensors (camera, IMU, thermometer, GPS, etc), typically one set of sensors per stream.
• The file and each stream contain an independent set of tags, which are string name/value pairs that describe them.
• Streams may contain Configuration, State and Data records, each with a timestamp in a common time domain for the whole file. Typically, streams contain one Configuration record and one State record, followed by one to millions of Data records.
• Records are structured as a succession of typed content blocks. Typically, content blocks are metadata, image, audio, and custom content blocks.
• Metadata content blocks contain raw sensor data described once per stream, making the file format very efficient. The marginal cost of adding 1 byte of data to each metadata content block in a stream is 1 byte per record (or less when lossless compression happens).
• Records can be losslessly compressed using lz4 or zstd, which can be fast enough to compress while recording on device.
• Multiple threads can create records concurrently for the same file, without CPU contention.
• VRS supports huge file sizes (tested with multi-terabyte use cases).
• VRS supports chunked files: auto-chunking on creation and automated chunk detection for playback.
• Playback is optimized for timestamp order, which is key for network streaming.
• Random-access playback is supported.
• Custom FileHandler implementations can add support for cloud storage streaming.