result-video-bench — kinescore physics scores over generated robot video

Just want the score? Read HOW_TO_READ.md. Each cell's pred/scored.jsonl gives every clip a 1–5 severity + the exact frames that go wrong; score_summary.json rolls the cell up. The raw 31 metrics below are the layer underneath.

Physics-plausibility scores for world-model / video-generation rollouts, produced by kinescore. Each clip's RGB is read into robot joint angles by a per-robot learned reader, joints are pushed through the robot's URDF forward kinematics to 3-D keypoints, and ~31 physics rulers (jerk, rigidity, joint-limit, collision, torque, …) are measured on that trajectory. See METHODS.md for every metric's definition and units.

Directory layout (mirrors the source dataset)

dense/<embodiment>/output/<view>/<generator>/<horizon>/<role>/
    results.jsonl     one JSON record per clip: all metric scalars (+ reason when N/A)
    traces.npz        per-frame arrays (jerk-over-time, …) keyed <clip_hash>/<metric>
    cell_info.json    robot, reader, val-mm, fps, packing, n_clips for this cell

• embodiment ∈ {humanoid, single_arm, bimanual} — the coarse on-disk group, not the robot. One embodiment can be two robots (see robot map below).
• view ∈ {multiview, singleview}. generator ∈ {ctrlworld, dreamdojo, dreamgen}.
• horizon ∈ {makovian, non_makovian}. role ∈ {pred (the generated video), gt (the real reference, when the cell ships one)}.

Which robot generated which cell (robot map)

embodiment is not the robot. Resolved per (embodiment, generator):

Scoring a cell with the wrong robot's reader would compare the wrong joints — hence this map.

Frame rate — per generator/robot (load-bearing)

Metrics with a non-zero dt exponent scale with frame rate. fps is not uniform across the benchmark; it is probed from each clip with ffprobe and stored per clip (dt field).

Cross-fps comparison caveat. Because e.g. mean_jerk_mps3 scales as 1/dt^3, the same motion at 16 fps vs 10 fps differs by (16/10)^3 = 4.096 — that is frame rate, not physics. Compare within the same fps, or dt-correct before comparing across generators. Every metric's dt exponent is listed in METHODS.md; each clip's resolved dt is in results.jsonl.

Readers and their accuracy gate (keypoint mm)

Every reader is graded by held-out 3-D keypoint error in mm (predict joints → FK → compare to keypoints the real logged joints produce). Accepted band ≈ 19–20 mm; the untrained baseline is 359.93 mm. A reader far outside the band is reported, not hidden.

Readers were trained on real joint ground truth, never on the generated video they score: ctrlworld readers on the real teleop trajectories that conditioned Ctrl-World (same fps / resolution / cameras as the scored clips); singleview readers on the real footage the dreamdojo/dreamgen clips were generated from. joint_source: "real" throughout.

Reading a score

results.jsonl — one record/clip: clip (path, n_frames, fps, dt, resolution), run (robot, reader_id, suite), metrics (scalar per key; null = not measured, with a reason in metrics_unavailable — never read as 0/perfect), coverage, status.

traces.npz — per-frame arrays under "<clip_hash>/<metric>"; the reduction each metric's scalar applies (mean/max) is in METHODS.md. These are the raw material for locating which frames a violation happens in.