Short answer
Estimate demonstration video storage by multiplying bitrate by recorded seconds by camera count, then adding allowances for sensor streams, derived files and copies. Transfer time follows from size and effective link speed. The numbers on this page are synthetic worked examples; your own codec, resolution and retention choices set the real figures, and delivery terms should cover format, integrity checks and sanitization of copies.
The buyer's problem
Video programs surprise teams in two ways. Sizes are larger than expected because multi-camera rigs multiply everything, and the files that arrive are larger still when suppliers keep near-original quality. Then transfer takes days over an ordinary link, copies multiply across vendors and cloud buckets, and nobody has agreed who deletes what.
A sizing method lets you write realistic limits into a contract before the first clip is recorded. It also exposes the quality trade-offs behind the numbers, such as whether a bitrate low enough to be cheap is good enough for hand tracking. For what to check in the files themselves, see acceptance criteria for demonstration video.
A worked sizing method
All values below are illustrative and invented to show the arithmetic. Replace them with your own.
Step 1. Per-camera storage. Size equals bitrate times duration. At a hypothetical 8 megabits per second, one hour is 8 × 3,600 = 28,800 megabits, which is 3,600 megabytes or about 3.6 GB.
Step 2. Multiply by cameras and hours. A rig with 4 synchronized cameras recording 100 session-hours produces 4 × 100 × 3.6 GB = 1,440 GB, about 1.4 TB. The 100 hours is an arbitrary input chosen to show the arithmetic, not a recommended or minimum dataset size.
Step 3. Add other streams. Depth, IMU, audio, gaze and logs each add their own volume. Depth video can exceed color video if stored uncompressed.
Step 4. Add derived and duplicate files. Proxy videos, extracted frames, masks and annotations accumulate. Keeping originals plus a working copy roughly doubles the footprint before backups.
Step 5. Add overhead for rejected material. Raw capture includes clips that fail acceptance. If a buyer-set share is rejected, raw storage rises by that proportion while delivered storage does not.
Step 6. Compute transfer time. Time equals size in bits divided by effective throughput. For 1.4 TB (about 11,200 gigabits) over a nominal 1 gigabit per second link at an assumed 50% effective rate, that is about 22,400 seconds, or just over 6 hours, before retries and verification.
# Illustrative arithmetic only - synthetic inputs
camera_GB_per_hour = bitrate_Mbps * 3600 / 8 / 1000
video_GB = camera_GB_per_hour * cameras * session_hours
other_streams_GB = depth_GB + audio_GB + imu_GB + gaze_GB + logs_GB
derived_GB = video_GB * derived_factor # proxies, frames, masks
working_set_GB = (video_GB + other_streams_GB + derived_GB) * copies
transfer_hours = working_set_GB * 8 / (link_Gbps * efficiency) / 3600
Parameters that move the answer
| Parameter | Typical decision | Effect on size or time |
|---|---|---|
| Bitrate | Set by codec, resolution, frame rate and content motion | Linear in storage |
| Codec | Efficient lossy codec vs near-lossless | Large differences; affects hand-detail quality |
| Frame rate | Match to hand speed and sync needs | Raises bitrate when increased |
| Camera count | Single wearable vs multi-view rig | Linear in storage |
| Depth | Compressed vs raw | Can dominate for depth-heavy capture |
| Audio | Included or removed | Small compared with video |
| Copies | Supplier archive, buyer ingest, backups | Multiplies working set |
| Link | Dedicated transfer vs shared office link | Sets days vs hours |
Motion-heavy hands and cluttered scenes need higher bitrates than static scenes to keep detail. Do not choose bitrate only for cost; run a pilot and check that hand pose and annotation quality survive compression.
Delivery mechanics
Very large deliveries do not always move over the network. Options include supplier-hosted download with expiring links, buyer-side cloud storage the supplier writes into, shipped encrypted drives, or staged deliveries by batch. Each has different controls for access logging, resumption and cost.
Agree on:
- Format and container. Video file naming, folder structure and manifests; for mixed sensor logs, containers like MCAP hold multiple timestamped channels with optional indexes and compression and are serialization-agnostic (Foxglove MCAP). Choose what your tooling reads. See video dataset delivery formats.
- Integrity. Checksums per file, a manifest that lists every file, and a rule for corrupt files.
- Batching. Deliver in tranches tied to acceptance so you can reject early rather than after the full transfer.
- Egress and handling costs. Who pays for transfer, drive shipping and temporary hosting.
- Retention at the supplier. How long they keep originals and under what protections.
- Deletion and sanitization. When copies, drives and caches are removed. NIST SP 800-88 Rev. 2, published in September 2025, supersedes Rev. 1 and is a common reference for media sanitization (NIST); ask which method applies to each medium and what certificate or record the supplier provides.
Licensing terms that touch delivery, such as permitted copies and subprocessors, belong in the wider licensing terms for robotics training data. This is not legal advice.
How rig design drives volume
Two design choices dominate the estimate. The first is camera count: a multi-view synchronized rig multiplies every hour by the number of views, so decide whether each view earns its place. The second is depth. Depth streams from RGB-D capture can be stored compressed or raw, and the choice can change the depth volume by an order of magnitude. Settle both in the pilot, measure real bytes per hour from the pilot files, and replace the assumed bitrate in the arithmetic above with the measured one.
What a storage estimate cannot tell you
An estimate does not say how many hours you need; that depends on architecture, tasks and embodiment. It does not tell you the quality of the video at a given bitrate; only samples do. It does not account for later re-encoding, annotation tools that generate large intermediate files, or training pipelines that decode frames into much larger tensors. Existing footage may already be compressed heavily, so size per hour of archive footage can be far lower than a purpose-built rig produces; see curating raw workplace video.
Illustrative delivery clause topics
# Illustrative only - topics, not contract language
delivery:
method: "expiring download links in tranches" # or buyer bucket, or encrypted drives
tranche_size: "buyer sets; each tranche subject to acceptance"
manifest: [file_path, bytes, checksum, duration_s, fps, codec, camera_id]
integrity: "checksum verified on receipt; failures re-sent at supplier cost"
retention_supplier: "originals kept N days after acceptance, then sanitized"
deletion_record: "written confirmation naming method and media"
buyer_copies: "listed locations; no additional copies without notice"
egress_costs: "allocated in agreement"
Questions to ask suppliers
- What bitrate, codec and frame rate do the originals use, and are originals retained or only compressed copies?
- What is the total size by modality, and how many files does the manifest list?
- How will data move to us: download, buyer-owned cloud, or shipped drives, and who bears each cost?
- Can delivery come in tranches tied to acceptance tests?
- Which checksum scheme and manifest fields do you provide?
- How long do you keep copies, where, and how will they be sanitized when the period ends?
- What happens to intermediate files such as proxies and extracted frames?
- Do you use subprocessors or third-party hosting for transfer, and who are they?
- What is the plan for resuming or re-sending after a failed transfer?
Explore your options
If you are sizing a purchase or a collection, describe the modalities, volume and delivery constraints to SourceX. SourceX looks for US businesses that hold the data you describe, checks the data and the supplier's licensing permissions, and coordinates license and delivery. SourceX reviews the requirement and follows up about potential sources; a request does not guarantee a match. For wider navigation, see the workplace task demonstration hub and the humanoid training data guide. The site's licensing terms page describes how licenses are set out.
Explore sourcing and licensing options with SourceX
Sources
- NIST SP 800-88 Rev. 2 Guidelines for Media Sanitization — media sanitization reference for retiring copies and drives.
- MCAP — open container for multichannel timestamped log data.