Managed vs Crowdsourced Egocentric Video Collection

Managed egocentric collection is a program. A buyer describes what a model is missing, that becomes a written skill spec with accept and reject criteria, contributors capture to the spec on hardware the program supplies, and every batch is checked, anonymized and delivered under a stated licence. Capture, QA and paperwork run as one pipeline with one party accountable for all of it.

On this page, crowdsourced egocentric video means something deliberately generic: many contributors recording first-person tasks on their own phones, in open, gig-style programs with light instructions. It describes a method, not any named platform or app, and practices differ between programs. Wherever the crowdsourced side is described, this page says what usually varies and what to ask. It quotes no third-party specs, accuracy figures, rates or prices.

The comparison is distinct from two nearby ones. In-house vs outsourced (/compare/in-house-vs-outsourced-egocentric-data-collection) asks who runs the capture program. Egocentric vs internet video (/compare/egocentric-vs-internet-video) asks whether footage was purpose-captured at all. This page assumes both options are purpose-captured and compares the method: a calibrated, spec-driven managed rig against open phone recording.

Managed does not mean only the full instrumented rig. A Firsthand engagement can use a phone mount, a 360 head-mount or the full instrumented rig, chosen in the spec. What makes it managed is the process around the camera. Per-tier stream lists are not stated on this page, so the stream specs below describe the full rig.

A plain phone clip is a single RGB video file from a camera that a contributor holds, wears or props up. What a robot-learning pipeline wants beyond RGB has to be recorded at capture time or inferred afterwards, and the table above shows which of those a managed collection records.

Depth is the first gap. Firsthand recovers depth from a calibrated stereo pair at 848×480 and 30 fps, in metric millimetres with a confidence value. A phone clip carries depth only if the capture app records it, and that varies. Motion is the second: a managed rig records 6-DoF IMUs at 200 Hz on the head and on each wrist, while whether a crowdsourced program records or delivers any motion data is not stated in general.

Hand pose is the third, and for manipulation work the most consequential. A managed collection delivers 3D hand pose with 21 joints per hand in metres, in the head-camera frame, with a per-joint visibility flag, recorded at capture time. From a phone clip the same information would have to be inferred afterwards from 2D pixels, which is the same limitation the site describes for scraped video in /compare/egocentric-vs-internet-video. Action labels follow the same pattern: managed delivery includes frame-accurate action segments with verb, noun and nanosecond timestamps, and contact events for the moment a hand meets an object.

Viewpoint is a quieter gap. The full rig uses a head-mounted global-shutter camera at 4K and 60 fps with a 120° lens, plus two wrist cameras at 1920×1080 and 60 fps. When contributors use their own phones, how the phone is mounted, and at what height and angle, can differ from person to person, and that changes the viewpoint distribution a model sees.

None of this makes phone video useless. It makes it a different input: RGB footage whose geometry, timing and labels you may need to establish yourself. Whether that is enough depends on what your model needs, which the later sections cover.

In a managed collection, every sensor is hardware-triggered onto a single PTP clock. The site reports a median absolute timestamp offset of 1.12 ms between the head camera and every other stream over 12,480 measured frames, a 99th-percentile figure of 1.94 ms and a 2.0 ms ceiling. Intrinsics and extrinsics are re-solved with a checkerboard target at the start and end of every session, reprojection error is held under 0.28 pixels, and the drift between the two solves is written into episode metadata. That is what lets drift be detectable rather than assumed away.

Each delivered episode carries int64 nanosecond timestamps per stream on the shared PTP domain and a calibration group holding intrinsics, extrinsics and reprojection error for the session. A buyer can therefore check sync and geometry from the data itself instead of taking either on trust.

A phone recording runs on the clock of one device. If a program combines more than one device or sensor, aligning them becomes a software problem solved after capture. As /compare/in-house-vs-outsourced-egocentric-data-collection notes, software timestamping drifts over a session, which is why a credible multi-sensor rig uses a hardware trigger line and a shared clock. Whether a crowdsourced program records calibration at all varies and is not stated here.

Why it matters: wrist cameras, head camera, depth and IMU only describe one action if they line up. A hand pose that is a few frames out of step with the video teaches a model the wrong relationship between what the hand did and what the scene showed. When you evaluate a source, ask for the sync ceiling, how it was measured, and whether calibration files ship with each session. For a deeper treatment of each, see /custom-collection/calibrated-egocentric-video-data and /custom-collection/time-synchronized-egocentric-data.

Managed collection puts the quality bar in the spec. The first stage names the skills, coverage targets and accept and reject criteria. The validation stage runs a sync check and a QA pass, then rejects and recaptures what fails, and the buyer sees the reject log. The documented reject bar covers sync breaches, calibration drift, object-out-of-frame, invalid depth, undocumented bystanders and spec mismatches, and failures are recaptured rather than shipped with a caveat.

The same bar defines what counts as an hour. A validated hour is 60 minutes of footage that has passed QA against your spec: sync within the 2 ms ceiling, calibration solved and within drift tolerance, coverage cells filled, and consent documented. Billing is on validated hours, so rejected or off-spec footage is not something a buyer pays for. Failure cases such as transit, occlusion and low light are shipped rather than trimmed, with a published reject log, so you see the hard footage as well as the clean footage.

Task spec adherence is the other half. In a managed collection, a clip is judged against a written spec, so a clip that shows the wrong task, or leaves the object out of frame, fails. In an open program with light instructions, how a clip is judged on-task varies. Ask who reviews each clip, against which written criteria, what happens to rejected clips, whether coverage targets exist and whether a reject log is shared.

The difference is not that open programs have no review. It is that a buyer needs to see the criteria and the rejects to know what the remaining footage represents. If those are not stated, the quality of a corpus is something you will end up measuring yourself.

In a managed collection, every participant signs a written release granting commercial training rights before capture begins. Releases are stored per item and per jurisdiction, and each batch carries consent artefacts and a data card listing jurisdictions of capture. Faces, plates and screens are detected and blurred and audio is scrubbed of identifying speech before anything leaves QA. If a bystander cannot be de-identified, the clip is discarded rather than shipped.

The licence is a stated term of the engagement: perpetual, irrevocable, buyer-owned and commercial. The buyer’s rights to the data and to any derived model are therefore defined by that licence rather than assembled contributor by contributor. See /guides/buyer-owned-training-data for what that structure covers.

For a crowdsourced source, the paperwork depends on the program’s own terms. The questions are practical ones. Do the contributor terms grant rights to train models commercially? Do those rights extend to a downstream buyer, and for how long? Are bystanders and screens handled before the footage is distributed? Is there a record of where each clip was captured? Provenance is only as strong as the records that travel with the data.

This is a procurement checklist, not legal advice; have counsel review any licence before you rely on it. The practical test is simple: ask for the release text, the anonymization description and the licence, and treat any item that cannot be produced as not stated.

Crowdsourced phone video can be the right input under some conditions, and it is worth being plain about them. It tends to fit when your model needs breadth of scenes and viewpoints in plain RGB more than it needs depth, motion or hand pose, when you plan to add your own labels or run your own pose estimation, or when you are exploring whether a task is worth specifying at all.

It also fits when you have the capacity to do the quality work yourself. If you will check calibration assumptions, review each clip against your own criteria and filter rejects, the cost of an open program shifts from the provider to your team, and for some projects that is an acceptable trade. And it fits when the licence and consent terms are explicit, readable and compatible with how you will use the data.

A sensible way to find out is a small trial of your own. Collect a bounded sample, score it against the criteria in the scoring table below, and see whether the missing streams and labels matter for your model. If they do not, you have saved effort. If they do, you will know exactly which fields a managed spec needs to carry.

A managed collection tends to pay off when the model needs aligned streams: depth, IMU, 3D hand pose and action segments tied to the same clock as the video. It also fits when the data must cover a specific skill or environment that an open program will not target on request, and when a spec with coverage targets is the only way to know what the dataset contains.

It fits when the rights matter. If you need buyer-owned commercial rights, signed releases stored per item and per jurisdiction, anonymization before anything leaves QA and a data card that travels with each batch, a managed engagement ships those as standard terms rather than as items to negotiate.

And it fits when speed to a first usable batch matters. The site reports a median of 48 hours from signed spec to first validated batch, measured across Spec Pilot engagements in environments where coverage is already deep. Thin scenarios take longer to staff. The pilot is on-demand and custom: a small, fast first batch that proves the spec and QA bar hold before volume scales. See /custom-collection/egocentric-video-data-collection for how a collection is run end to end.

The two approaches are not exclusive. Some teams use broad RGB footage for visual diversity and a managed collection for the skills where depth, hand pose and labels decide whether training works. Treat the choice as a per-skill decision, not a one-time commitment.

Start from the gap, not the finished spec. Describe a task, environment or population the model is missing. That becomes a written spec with the elements in the table above: the named skill list, coverage targets, capture tier, annotation depth, accept and reject criteria, jurisdictions, delivery format and a pilot. See /custom-collection/spec-driven-egocentric-data-collection for how a skill spec is structured.

Be specific about the reject bar, because that is where specs succeed or fail. State what makes a clip unusable for your model, whether that is the hands leaving frame, depth failing, an undocumented bystander or the wrong task, and the program will check every episode against it. State the format your training pipeline expects: RLDS, LeRobot, WebDataset, HDF5, zarr or Rerun .rrd, each carrying the same canonical episode content with only the container differing.

Then run the pilot. A Spec Pilot is a small, fast first batch sized to prove the spec and QA bar on real footage. Use it to check stream quality, annotation fidelity and format compatibility with your own pipeline before committing to volume. If something is off, the spec changes, not the data. Once the pilot passes, the same pipeline scales to the target size in scheduled batches against a running accept and reject ledger.

What this page does not state: pricing, per-tier stream lists, contributor counts or any throughput figure. Those are quoted per engagement. For the cost drivers that apply, see /custom-collection/pricing.