Media capture

Normative.

Video of a swing is useful and almost entirely unlike every other kind of data in this standard: it is large, it is continuous, it is legally sensitive, and the moment worth keeping has already passed by the time anyone knows a shot occurred.

1. Ring buffer, triggered extraction#

A camera participant holds a continuous rolling buffer and never writes anything until told to.

   ┌──────────────── 10 s rolling buffer ────────────────┐
   │                                                     │
   │   ← pre-roll 5 s →  │ SHOT │  ← post-roll 5 s →     │
   └─────────────────────┴──▲───┴────────────────────────┘
                            │
              engine reports a shot; extraction begins

• Default 5 seconds before, 5 seconds after. Configurable; the buffer must be at least pre-roll + post-roll.
• The trigger is the engine's shot event, not the camera's own motion detection. Motion triggers fire on a player walking past.
• Nothing is retained without a trigger. An untriggered buffer is overwritten in place and never touches disk.
• The engine's shot event arrives 100–200 ms after impact, because that is the launch monitor's own latency. The buffer is what makes that irrelevant — which is the entire reason for this design rather than starting a recording on a shot.

Post-roll ends, the clip is cut, and the buffer returns to overwriting.

2. Extraction should not re-encode#

If the source already delivers H.264 or H.265 — every network camera does — cut on keyframes and copy the stream rather than decoding and re-encoding.

A bay PC is already running a simulator. Re-encoding ten seconds of 1080p while a golfer is waiting for the next shot is a visible, avoidable cost. Stream-copy extraction is close to free.

This needs a keyframe interval no longer than one second, otherwise a clean cut is impossible without re-encoding. Cameras SHOULD be configured that way; a camera that cannot is a re-encode case and should declare it.

3. Video never touches the live path#

Clip extraction, compression and upload are bulk path (09 §3). They MUST NOT share a connection with shot data, MUST be rate-limited, and MUST be freely delayable.

A stalled upload has no effect on play. A bay with no internet buffers clips and uploads later, or never — and the round is unaffected either way.

3a. Separate path, and separate record#

09 §3 separates the transport. This separates the record, which is a stronger claim and the one that keeps the rest of the design simple:

Media and time-series data are not part of the scoring corpus. They do not define scoring, and nothing about rating, posting or settling a round may depend on them.

A clip and a 240 Hz pelvis trace are large, are produced for the player's own benefit, and say nothing about what was scored. So they take a different path to a different store with its own lifecycle, and the scoring record is complete without them.

Normative:

• The scoring record MUST be complete and ratable with no referenced blob present. A round that never uploads a single clip rates, posts and settles identically to one that uploads all of them.
• The link from record to blob is a seriesRef-style handle: an opaque reference plus a digest. The reference locates the object; the digest is what proves the object retrieved is the object that was recorded. A handle without a digest is not sufficient, because a blob that can be replaced after the fact is not evidence of anything.
• The handle MUST NOT encode member identity, a bay, or a time, for the same reason as every other identifier that leaves the bay (00 §6).
• A de-identified record MUST NOT carry a media handle. In practice one never could — §5a gates capture on consenting membership, so an unclaimed round has no media to point at — but the prohibition is written down so the link is not added later by somebody solving a different problem.

Local retention has to be bounded, and this is where media differs operationally from everything else. Scoring data is small enough that an offline bay can queue weeks of it harmlessly. Media is not: a few rounds of 1080p60 clips will fill a disk. So an engine MUST be permitted to evict un-uploaded media under a stated local policy, and eviction MUST NOT invalidate the round or mark it incomplete. The clip was always the optional half.

4. Camera placement#

The normal installation is a dedicated camera for SGA, attached to the simulator PC and pointed at the player. Nothing else wants it, so device exclusivity is a non-issue in that setup. An operator monitoring the room will have a security camera somewhere else with a wider view; that is a different device serving a different purpose and the two never meet.

4.1 Where exclusivity does still bite#

Narrowly. On every desktop OS a USB or UVC camera is generally exclusive to one process, which matters in two real cases:

• A launch monitor's own swing cameras. Several vendors ship USB cameras driven by their software. That software holds the device.
• Coaching software already installed — a teaching facility running video analysis on the same machine.

Where either applies, one participant owns the device and re-exposes it rather than several components fighting over the handle. Otherwise a dedicated camera just works, and a participant that opens a local device declares exclusive_device: true so the operator can see what is claimed.

4.2 Handedness decides where the camera goes#

A face-on view is not one position. A right-handed player stands to the right of the target line looking down it; a left-handed player stands to the left. A single fixed camera gives you a face-on view of one handedness and a view from behind for the other.

That matters differently depending on the purpose:

So for competition tiers where the point is confirming who swung, the bay needs either two cameras or one camera whose position is selected by handedness. A single fixed camera satisfies it for right-handed players only, which is not a certification a tier can honestly grant.

The bay profile records covers_swing_position; competition tiers should require it to hold for both handednesses.

4.2a A mirrored pair does double duty#

Two cameras at mirrored positions either side of the hitting area solve the handedness problem twice over, and the second use is the more valuable one.

Camera selection. Classify which camera sees the player's front, and record the clip from that one. Face-on coverage for both handednesses, automatically, with no operator setting.

Handedness detection. The same classification is the answer to which side the player swings from — and that is a setting simulators and some launch monitors require, which today is configured by hand and routinely forgotten. The engine can determine it and pass it on.

That reframes the second camera. Under §4.2 it was a cost incurred for the occasional left-hander. Here it earns its place on every shot, for every player, by removing a manual setup step that is silently wrong when nobody changes it.

The classification is not identity. Deciding whether a person faces toward or away from a camera does not identify anyone and builds no template. It stays outside the biometric regime in 08 §4.2, and it MUST stay there:

• runs locally, on the bay
• operates on a frame from the ring buffer, which is discarded immediately
• produces one value — front or back — and retains nothing else
• MUST NOT perform face recognition, build a template, or attempt to distinguish which person is present

It is also a small model. Binary classification, fixed cameras, fixed background — no GPU, and comfortably inside the gap between shots.

Handedness is standing state, per 03 §2.2a. It is asserted between shots, changes when the group rotates, and MUST be retractable when the view is obstructed or two people are in frame. Ambiguity means report nothing, never guess — the same rule as the club rack.

When the observation disagrees with the simulator's setting, that is the finding, not a nuisance. A sim configured for a right-hander while a left-hander plays mirrors the shot, and every number after that is wrong in a way nobody notices for a whole round.

Nothing needs to record the disagreement, because nothing merged the two answers in the first place: a camera pair publishes player.lm_handedness and the simulator publishes player.sim_handedness, both survive into the record, and a reader compares them (03 §3.4f). A flag asserting that two visible values differ would be one more thing that can be wrong about something anyone can check.

This may be the most useful thing a camera pair does, and it has nothing to do with video.

Handedness has several possible sources — an observation, a launch monitor, the simulator's setting, a member's profile — and the connection matrix resolves them like any other field. observed is evidence; sim_setting and member_profile are claims a human made once. Exactly the club-identification distinction, for exactly the same reason.

4.3 Cable runs#

A face-on camera sits perpendicular to the target line, several meters from the PC and often downrange near the screen. Passive USB is good for roughly five meters at USB 2.0 and less at USB 3.

That is the practical reason to consider a network camera, rather than exclusivity — position it where the view is, power it over Ethernet, and stop thinking about cable length. It also happens to remove the contention cases in §4.1 for free.

5. Binding, consent and retention#

A clip binds to a slot and a shot, never to a person — the same rule as everything else leaving the bay (00 §6).

• Capture MUST be off unless consented for the session, or required by an event the players entered knowingly.
• Consent is checked at upload, not at capture, so a player who claims a slot late still gets their own clips and a player who opts out suppresses them retroactively.
• One opt-out in a session suppresses capture for the whole session. A camera pointed at a bay records everyone in it.
• Retention is purpose-bound and stated: player review, coaching, and human verification of a tournament result. Around 30 days, covering processing and a dispute window, then purge.

5a. Two gates, and they ask different questions#

Swing video and swing kinematics are the two heaviest things the bay can produce and the two most sensitive. Capture is therefore gated twice, and the gates are not the same rule applied at different times — they ask different questions about different people.

The permission gate — unanimous, and about everyone the camera can see. Capture stays off unless every person present is an SGA member who has consented to capture for this session. Not every player: every person. One non-member in the bay, or one opt-out, and nothing is captured for anybody.

The unanimity follows from the bullet above — a camera pointed at a bay records everyone in it. The membership requirement is what makes the consent meaningful: consent from somebody SGA has no relationship with cannot be recorded, evidenced, or withdrawn later.

The entitlement gate — per slot, and about who gets a clip. Inside a bay that has passed the permission gate, a clip is produced only for a slot whose occupant is entitled to one. This is a cost boundary rather than a privacy one, and it is deliberate: media moves only where somebody is paying for it to move.

The entitlement crosses as a slot capability, never as identity. 00 §6 is unchanged — the bay learns that the occupant of slot 2 may have clips, and learns nothing else about them. This is the same narrow shape as round.allowances: round-scoped, per-slot, carrying no member identity, resolvable to a person only by the cloud.

Arm per shot, not per session. The engine already knows whose turn it is (round.player_up), so buffer arming follows the entitlement. A non-entitled player's swing is then never written rather than written and discarded. Bandwidth follows entitlement by construction, and the privacy posture is better for the same reason: not capturing beats capturing and deleting.

Re-evaluate continuously, not once at round start. Somebody joins on the seventh hole. If they are not a member, or not consenting, the permission gate closes mid-round and capture stops. What is already buffered is handled by the existing rule that consent is checked at upload rather than at capture.

The honest limit: the roster is not the room. A camera sees spectators, staff, and the group waiting behind. None of them are in round.roster and the engine has no way to know they are there. The permission gate is therefore necessary and not sufficient, and the rest of the answer is physical rather than protocol: framing that covers the hitting area and not the seating (§4), a recording indicator a person can actually see, and notice posted at the facility. This specification can require the first. It can only assume the other two, which is why they belong in the facility's obligations rather than here.

Status: not implemented. The gates are recorded now so that the capability is not built without them.

Automated identity confirmation from video is out of scope and is not built. That is biometric identification and carries a regime — Illinois BIPA, Texas CUBI, GDPR Art. 9 — that the rest of this is deliberately outside. Human review of a clip is not the same thing, and keeping the two apart is what lets everything above stay simple.

6. What a camera participant declares#

{
  "roles": ["recorder"],
  "provides": [
    { "field": "media.swing_clip", "provenance": "measured",
      "timing": "shot_synchronous" }
  ],
  "wants": [ { "field": "status.sim_ready", "reason": "buffer arming" } ],
  "media": {
    "source": "rtsp",
    "exclusive_device": false,
    "buffer_s": 10,
    "pre_roll_s": 5,
    "post_roll_s": 5,
    "resolution": "1920x1080",
    "frame_rate_hz": 60,
    "codec": "h264",
    "keyframe_interval_s": 1,
    "stream_copy_capable": true
  }
}

The clip itself is referenced from the shot record, never inlined — a seriesRef-style handle into the journal (common seriesRef).