THE STEP the trail THE WHY headlights
THE STEP the trail THE WHY headlights

VIDEO DATA. BUILT IN THE EEA

A frame tells you where. A sequence tells you why.

We collect video against the task your model has to solve, with specified coverage, quality control and documented rights.

A model trained on frames learns where things are. The change between frames is where the decision lives, and it is what this collection is specified to capture.

00:00:00:07 AS SPECIFIED · 30 FPS FRAMES IN THE STEP 7

The clock counts the frames laid into the step. Drop frames removes every frame the platform would flag as dropped or duplicated, the same check it runs on every recording.

WHAT YPAI COLLECTS OWNED 08 · ROUTED 03

Start from the movement your model is missing

Eight programmes YPAI runs, and three adjacent kinds of work with their own pages. Each door carries one sentence on the movement it captures; open it for the problem, the delivery and the annotation it hands off to.

  1. 01

    Collection at scale

    The same scene under every condition it will meet, not one good take.

    The problem and the delivery

    The footage your model needs does not exist, or misses the conditions it will meet.

    Scenario-based, quota-managed capture across countries, environments and devices, remote or moderated, with reshoot workflows and delivery manifests. A coverage gap becomes recording instructions.

    Coverage is specified per cell before volume is counted.

  2. 02

    In-cabin and dashcam

    A glance away from the road is a change between frames, not a frame.

    The problem and the delivery

    Driver, occupant and road-facing models need European cabins and roads under real conditions.

    Driver monitoring, occupant monitoring, cabin activity and road-facing video, captured across the drivers, vehicles, lighting and weather the deployment will meet. Voice in the cabin is its own programme.

    Deployment-representative coverage of cabin and road, with geographic scope defined against the intended use.

  3. 03

    Human motion, gesture and pose

    An action has a start and an end; the boundary is what the model learns.

    The problem and the delivery

    The model needs movement, interaction or several views of the same action.

    Full-body and upper-body motion, gestures, locomotion and action sequences, with multi-view synchronisation where the task requires it. Pose and keypoint labels are annotation work and have their own page.

    Synchronised human-action video collected for the temporal task, not stills.

  4. 04

    Video integrity and synthetic media

    Manipulation shows between frames before it shows in one.

    The problem and the delivery

    Detection models go stale as generation methods move, and benchmarks hide their failure modes.

    Manipulated-media datasets, synthetic-media evaluation, authenticity review and human-perception studies, on provenance-aware footage. Handling and purpose limits are agreed per engagement.

    Real footage with its record, so the real side of the benchmark is never in doubt.

  5. 05

    On-camera speech and conversational video

    The mouth moves before the sound arrives; the offset is measurable.

    The problem and the delivery

    Visible speakers, audio-video sync and lip-sync-sensitive data, recorded as one programme.

    Solo, paired and multi-speaker recording with isolated speaker tracks, transcription and diarisation, demographic and language quotas. Speaker recruitment and the consent record live on the speech hub.

    Isolated per-speaker tracks and audio-video sync fixed in the specification.

  6. 06

    Licensed video datasets

    A licensed clip carries its provenance, or it is not delivered.

    The problem and the delivery

    The deadline does not allow custom collection, or a rights review failed on the set you have.

    Existing inventory identified, sourced through partners, sampled and technically reviewed, rights verified, licensed, packaged and delivered. Licence what exists and collect only what is missing.

    Chain of title and permitted use verified before a sample is shared.

  7. 07

    Indoor activity and consumer behaviour

    A fall, a hand-over, a purchase: each is a change across frames.

    The problem and the delivery

    Home, workplace and in-store models need everyday activity under the conditions people actually live in.

    Human activity, consumer behaviour and work-task video in indoor and outdoor environments, device and environment controlled, remote or moderated, with consent per contributor and purpose.

    Opt-in households and workplaces, not scraped footage.

  8. 08

    Face, identity and talking-head video

    Expression is movement; a still cannot hold it.

    The problem and the delivery

    Facial movement, expression, gaze and head pose across identities, sessions and lighting.

    Per-project consent and rights scope (model release, permitted use, reuse) shape how this delivery is set up, with file-to-participant traceability throughout.

    Repeated-session identity and speech-linked facial movement, traceable to the participant file.

  9. 09

    Speech and audio collection

    The task is the voice, with no camera in the loop.

  10. 10

    Egocentric and physical AI video

    First-person video, hand-object interaction and task demonstrations for robot learning.

  11. 11

    Video annotation and evaluation

    Tracks, temporal events, action labels and keypoints on footage you already hold.

Also collected 05

  • Indoor and outdoor scenario capture
  • Multi-country, quota-managed cohorts
  • Cross-device and cross-environment variability
  • Avatar and animation motion data
  • Gap-fill against footage you already own

Working with a scenario not listed here?

Describe the deployment and the condition it runs under, and YPAI designs the capture protocol.

Scope a programme

THE CONDITION SPACE Camera · Environment · People · Motion

Four axes decide whether a sequence survives deployment

You name the range your deployment has to hold. The programme is built to span it, and every recording lands with its coverage in its record.

Camera

The mount, the sensor and the rate are fixed in the specification, because a model trained on one capture mode degrades on another.

Range specified

  • Smartphone, fixed mount
  • Smartphone, handheld
  • Webcam
  • In-cabin camera
  • Frame rate and resolution selected for the task

Environment

The street, the cabin, the room. Light, weather and glass are specified, not hoped for.

Range specified

  • Street at blue hour
  • Automotive cabin and road
  • Home
  • Workplace and in-store
  • Rain, snow, night

People

Quota-managed cohorts, identity-verified, with the rights for every visible person recorded.

Range specified

  • Multi-country, quota-managed cohorts
  • Age range, gender identity, skin tone
  • Identity-verified contributors
  • Facial and biometric rights recorded

Motion

The change between frames is the edge case. It is captured on purpose, at the rate the decision needs.

Range specified

  • The same scene under every condition it will meet
  • Fast motion, frame rate selected for it
  • Occlusion mid-sequence
  • Low light
  • Dropped and duplicated frames

The reading in each tab is taken from the frame itself: sharpness as the variance of the Laplacian, and the share of pixels under 25 IRE. The platform takes the same readings on every recording it accepts.

Coverage is agreed before capture begins and delivered as part of the record. Where a required range cannot be covered, YPAI says so during scoping rather than after delivery.

HOW A PROGRAMME RUNS Specification · Capture · Quality gates · Delivery

One requirement becomes one accountable video operation

Model task, scenario, cohort, environment and acceptance criteria are written before capture. The same specification is what the footage is reviewed against, and what the delivery record proves.

  1. The specification, written first

    The model task sets scenario, cohort, environments, capture mode and acceptance criteria, before anyone records.

  2. The take, under the specified conditions

    Identity-verified contributors record under the specified conditions; rate, resolution and sync are fixed in the specification.

  3. The gate, accepted or returned with a reason

    Automated checks, then human review against the specification; a rejected item returns with its reason.

  4. The package, with its record

    Accepted footage leaves with its metadata, rights and provenance record, acceptance report, checksums and manifest.

YPAI PROPRIETARY DATA COLLECTION TECHNOLOGY PLATFORM · RECORD · RIGHTS

We built the system behind the data.

YPAI operates its own bespoke, GDPR-native data collection and assurance platform, built to produce high-specification AI data across speech, video, image, text, human feedback, agents, robotics and other multimodal programmes.

Identity
Asset, modality and schema version
Origin
Source, device, application, environment and time of creation
Contract
The requirements it was collected against, and their coverage
Privacy
Processing purpose, legal state and data categories; consent per visible person
Quality
Deterministic, statistical, learned, cross-modal and human assertions, with the verdict
Agreements
Applicable statements, their hashes and signatures
Verdict per recording
PASS

What the platform measures on every video recording

  • Native resolution and frame rate
  • Dropped and duplicated frames, bitrate and codec
  • Focus, exposure, motion artefacts and continuity
  • Audio-video synchronisation
  • Participant visibility, scene compliance and liveness
  • Camera provenance, facial and biometric rights
The chain, for one video asset

Specification Customer specification and agreements compiled into an executable project contract

The record your legal and security review will ask for

Governance artefacts are produced by the operation, not assembled afterwards. Depth and format follow your risk profile and are agreed during scoping.

What is the legal basis for each recording?

Consent, legitimate interest or contractual necessity, documented per recording

Explore the platform Inspect a sample assurance record →

START WITH THE SPECIFICATION Describe the system · Feasibility read · Pilot · Production

Bring the footage problem. Leave with a programme shape.

The specification
  1. 01 Describe the system Model task, target scenario, cohort or geography, scale and timeline.
  2. 02 Feasibility read Capture plan, coverage matrix, rights scope and acceptance proposal.
  3. 03 Pilot A scoped delivery against the agreed specification, reviewed before production.
  4. 04 Production Full programme with ongoing review, versioned delivery and support.
Video programme (optional)

Include the condition the model fails under, if you know it.

specified · reviewed · delivered with its record

We will define the video programme required for your deployment context and constraints.

If YPAI is not the right fit, we will say so directly.