Football Video Performance Analytics

Creator's demonstrated workflow

The supplied creator source describes a full computer-vision system built on YOLO, OpenCV, and Python:

1. Upload a regular match video: “No sensors, no GPS trackers, just camera footage.”
2. The neural network finds every player, referee, and ball on its own, every frame, in real time.
3. KMeans clustering breaks down jersey colors pixel by pixel and splits players into teams automatically, “without a single manual hint.”
4. Optical Flow tracks camera movement and separates it from player movement.
5. Perspective Transformation converts pixels into real meters.
6. Speed of every player, distance covered, and ball possession percentage are calculated automatically.

The creator also states: “Four hours of tutorial from zero to a working system.” The creator claims that the model is trained on real Bundesliga matches, runs on a regular GPU, and provides Python code that a user can “take ... and run.”

XSkills operational adaptations

XSkills operational adaptation - authorization gate and preflight

Inputs

• Confirmed authorization to process the supplied footage, especially where it is private or contains identifiable people.
• A video file and, if available, frame rate, duration, resolution, and capture details.
• A Python environment capable of executing code.
• OpenCV installation capable of decoding the supplied video.
• YOLO implementation and model weights available to the operator, including a documented class mapping for players, referees, and the ball.
• GPU availability and the ability to run inference on it, if the regular-GPU claim is to be tested.
• For meter-based outputs, visible pitch-reference points and their corresponding known pitch locations in meters.

Actions

1. Obtain and record the authorization confirmation before decoding, extracting, uploading, or otherwise processing the footage.
2. Verify that Python code can execute in the target environment.
3. Verify OpenCV can open the video, read frames, retrieve timestamps or frame rate, and report frame dimensions.
4. Verify the YOLO model and weights load successfully, and inspect the available class mapping for player, referee, and ball categories.
5. If GPU execution is available, run a short inference test and record device identity and measured throughput. Do not infer regular-GPU performance from the creator’s claim.
6. Inspect the footage for cuts, replay inserts, major occlusion, pans, zooms, and visible pitch markings.

Checks

• Confirm authorization is explicitly recorded.
• Confirm video frames are decodable and time can be assigned to each processed frame.
• Confirm the required model classes are available or identify missing classes.
• Confirm any proposed pitch-reference points are visible and distinguishable.

Outputs

• A preflight record containing authorization status, file properties, environment status, model/class status, GPU-test status where applicable, and known limitations.

Fallback

• If code execution, model weights, GPU access, or video access is unavailable, produce a plan-only implementation review. The plan must not report detections, real-time performance, speed, distance, or possession results.

Stop conditions

• Do not process private or identifiable footage without confirmed authorization.
• Stop execution if the video cannot be decoded, timestamps cannot be reasonably established, or the required YOLO classes are unavailable.
• Stop physical-unit metric computation if no defensible image-to-meter transformation can be documented.

XSkills operational adaptation - source-named detection with Python, OpenCV, and YOLO

Actions

1. Use Python and OpenCV to read the authorized match video frame by frame.
2. Apply the available YOLO model to each intended analysis frame for the source-named categories: players, referees, and ball.
3. Store each detection with: frame number, timestamp, class, confidence, bounding box, image center, and source-frame dimensions.
4. Preserve source frame references for later visual review.
5. Treat the creator’s “every frame, in real time” statement as a claimed design characteristic. Measure actual processed frames per second and report the tested environment rather than assuming that result.

Checks

• Review representative frames across the requested interval for players, referees, and ball detections.
• Record detection gaps, false-looking detections, cuts, and intervals where the ball is too small, occluded, or absent from view.
• Compare measured processing throughput with the source video frame rate only to determine whether the tested setup kept pace; do not claim general real-time operation.

Outputs

• Timestamped detection records.
• Measured inference and pipeline throughput.
• Optional annotated-video review output.

Fallback

• Mark unreliable detections and affected intervals as unresolved. Do not treat a missed detection as confirmed absence.

Stop conditions

• Do not generate downstream metrics for an interval when their required player or ball detections are persistently unavailable.

XSkills operational adaptation - tracking and identity association

The source states that the system finds players, referees, and the ball, but does not specify an identity-tracking method. The following is an XSkills implementation choice.

Actions

1. Create temporary, video-local track IDs separately for player, referee, and ball detections. These IDs are not names or real-world identities.
2. For each new frame, associate a detection with an existing same-class track only when it passes both of these gates:
   • its bounding-box overlap with the track’s predicted box is above a documented threshold; and
   • its image-center displacement from the predicted location is below a documented time-scaled threshold.
3. Predict the next box location from the last valid detection and its most recent image-plane motion. Start a new track if no existing track passes the gates.
4. Mark a track as interrupted after a documented maximum missed-frame interval. Do not bridge longer gaps as if identity continuity were known.
5. Retain association score, predecessor track ID, and interruption/restart status for audit.

Checks

• Review tracks during crossings, substitutions, occlusions, camera cuts, and rapid camera movement.
• Flag suspected identity switches rather than silently preserving a continuous identity.

Outputs

• Timestamped temporary track records with continuity and uncertainty flags.

Fallback

• Where identity association is not credible, retain frame-level detections without individual cumulative speed or distance metrics.

Stop conditions

• Do not attribute cumulative player distance or speed histories across an unresolved identity switch, cut, or prolonged tracking gap.

XSkills operational adaptation - source-named KMeans jersey-color team assignment

Actions

1. For each player detection or stable player track, extract color evidence from an interior upper-body region of the player bounding box. Exclude as much background, grass, and box edge as practical.
2. Convert the selected pixels to a documented color representation and collect representative jersey-color samples.
3. Apply KMeans clustering with two player-team clusters to the collected color evidence.
4. Keep referee detections outside player-team clustering.
5. Assign each player track a team-group label only when its cluster membership is sufficiently stable across documented observations. Otherwise assign unknown.
6. Preserve the cluster identifier separately from any display label such as team_1 or team_2; do not infer club names from colors.

Checks

• Visually inspect samples from both clusters across lighting conditions and camera views.
• Check goalkeeper kits, similar jerseys, shadows, compression artifacts, and occlusion separately.
• Confirm that cluster assignment is stable for the player tracks used in a team-level metric.

Outputs

• Team-group assignments, support observations, confidence or stability status, and unknown assignments where needed.

Fallback

• If KMeans does not meaningfully separate the two teams, preserve unresolved labels and request clearer footage or human review.

Stop conditions

• Do not calculate team possession percentages for intervals where the player-team assignments required for the calculation are materially unresolved.

XSkills operational adaptation - source-named Optical Flow camera-motion separation

Actions

1. Apply Optical Flow between consecutive frames to estimate apparent image motion.
2. Estimate dominant camera motion from features that are not associated with moving players, referees, or the ball where feasible.
3. Record the estimated camera-motion transform for each valid frame pair.
4. Preserve both raw image-plane object motion and camera-compensated motion. Mark compensated motion as an estimate.
5. Segment processing at camera cuts, replay transitions, or other discontinuities rather than applying one continuous motion estimate across them.

Checks

• Inspect representative static-camera, pan, tilt, zoom, and cut intervals.
• Verify that the estimated camera movement is not visibly dominated by player motion.

Outputs

• Frame-pair camera-motion estimates, segment boundaries, and camera-compensated image coordinates where credible.

Fallback

• For intervals with unreliable motion separation, retain raw image-space observations only or suppress movement outputs for those intervals.

Stop conditions

• Do not use an unreliable camera-motion estimate to calculate physical speed or distance.

XSkills operational adaptation - source-named Perspective Transformation and homography selection

Actions

1. Select at least four non-collinear visible pitch points in a stable camera segment, such as identifiable intersections or markings.
2. Document the image coordinates of each selected point and the corresponding known planar pitch coordinates in meters.
3. Compute a planar perspective transformation (homography) from the documented image points to the meter-based pitch coordinate system.
4. Check the transformation using additional visible pitch references not used to fit it where available.
5. Apply the approved transformation to an appropriate player ground-contact proxy, such as the bottom-center of a player bounding box, rather than automatically treating a box center as field position.
6. Store transformation identifier, selected reference points, residual or mismatch observations, segment scope, and calibration status with every transformed coordinate.

Checks

• Confirm selected points lie on the same pitch plane and are not repeated or nearly collinear.
• Compare transformed held-out pitch references with their expected meter locations.
• Review whether zoom, camera movement, or a changed view requires a new transformation segment.

Outputs

• Documented transformation records and timestamped meter-coordinate trajectories for valid segments.

Fallback

• If pitch points are insufficient or transformation quality cannot be checked, provide image-space trajectories only.

Stop conditions

• Do not output meter-based speed or distance without a documented and segment-appropriate perspective transformation.

XSkills operational adaptation - timestamped speed and distance formulas

Actions

For each continuous, identity-consistent track with valid transformed positions, use timestamped positions (p_i=(x_i,y_i)) in meters at times (t_i):

1. For each consecutive valid pair within the same continuous segment, calculate elapsed time: [ \Delta t_i=t_i-t_{i-1} ]
2. Calculate pairwise displacement: [ d_i=\lVert p_i-p_{i-1}\rVert_2 ]
3. Calculate instantaneous video-derived speed: [ v_i=d_i/\Delta t_i ] only where (\Delta t_i>0), the two observations are valid, and no tracking, camera-motion, or calibration interruption occurred between them.
4. Calculate distance over a stated interval as: [ D=\sum_i d_i ] using only valid consecutive pairs in that interval.
5. Report the number and duration of excluded gaps. Do not add distance across gaps, cuts, unknown identities, or invalid transformations.

Checks

• Review representative trajectories and speed values against the source video.
• Identify implausible jumps for visual review; flag or exclude them only under a documented rule rather than silently altering them.

Outputs

• Per-track speed samples with timestamps and units of meters per second.
• Distance totals in meters for explicitly stated continuous or aggregated valid intervals.
• Coverage and exclusion records.

Fallback

• If meter transformation is unavailable, report no physical speed or distance. Image-space motion may be reported only as image-space information, not as meters or physical speed.

Stop conditions

• Do not present a cumulative total as complete when unresolved gaps, identity breaks, or invalid calibration materially affect the requested interval.

XSkills operational adaptation - conservative ball-possession association

The source claims automatic ball-possession percentage but does not define possession. The following conservative association rule is an XSkills implementation choice.

Actions

1. At each timestamp with a valid ball detection, identify player detections with a known team-group label in the same frame.
2. Measure the image-plane distance from the ball center to each candidate player’s lower bounding-box region.
3. Assign the ball to one player only when:
   • the nearest candidate is within a documented proximity threshold scaled to that player’s bounding-box size; and
   • the nearest candidate is separated from the next nearest candidate by a documented ambiguity margin.
4. If either condition fails, if the ball is not detected, or if the player’s team is unknown, set possession state to unknown.
5. Require the same assigned team to persist for a documented minimum temporal duration before recording a confirmed team-possession interval. Set transition and contested frames to unknown rather than forcing an immediate switch.
6. Aggregate confirmed duration by team. For an analysis interval of duration (T), report: [ P_{team}=100\times T_{team}/T ] and separately report: [ P_{unknown}=100\times T_{unknown}/T ] so unassigned time remains visible. Team percentages need not sum to 100% when unknown time exists.

Checks

• Review sampled possession intervals involving passes, aerial balls, tackles, clustered players, off-screen ball movement, and ball occlusion.
• Confirm that the selected proximity, ambiguity, and persistence thresholds are recorded with the output.

Outputs

• Timestamped player/team/unknown possession states.
• Team possession shares of the full stated interval, unknown-time share, and observable-coverage summary.

Fallback

• If ball-to-player association is ambiguous, retain unknown possession. Do not assign possession to the nearest team by default.

Stop conditions

• Do not present a team-possession percentage as a complete match conclusion when unknown, unobservable, or unresolved time is material.

XSkills operational adaptation - review, reporting, and portable alternatives

Actions

1. Deliver only artifacts supported by the executed pipeline and documented prerequisites:
   • detection and temporary-track records;
   • team-group assignments;
   • camera-motion and transformation records;
   • speed, distance, and possession estimates where valid;
   • annotated review material when requested; and
   • a limitations and coverage log.
2. State the analyzed video interval, processed-frame policy, measured throughput, calibration status, unknown intervals, and all threshold choices used by the implementation.
3. Label the creator’s real-time, regular-GPU, Bundesliga-training, automatic-team-assignment, and automatic-metric statements as source claims, not independently verified guarantees.

Portable alternative - XSkills operational adaptation

If Python, OpenCV, YOLO, or their deployment environment cannot be used, XSkills may propose a portable substitute only as a separately documented implementation change. Do not represent that substitute as part of the creator’s stated Python/OpenCV/YOLO workflow, and do not claim that it preserves the creator’s stated results.

XSkills safety adaptations

XSkills safety adaptation - uncertainty and claims boundaries

• Treat all speed, distance, and possession outputs as video-derived estimates, not ground truth.
• Do not invent model versions, accuracy, training-data scope, hardware specifications, frame rate, calibration method, possession rule, or validation results.
• Do not generalize the creator’s Bundesliga-training claim to other leagues, teams, kit designs, camera systems, video qualities, or competitions.
• Preserve missing, ambiguous, unresolved, or failed intervals as such. Do not convert them into certain player, team, identity, or possession conclusions.
• Do not identify temporary video track IDs as named people without independently supported authorization and evidence.

XSkills safety adaptation - permitted-use boundaries

• Require confirmed authorization before processing private or identifiable footage.
• Review applicable recording rights, broadcasting restrictions, privacy obligations, and data-handling requirements before use.
• Do not use outputs as the sole basis for disciplinary, employment, contractual, medical, player-safety, betting, or match-outcome decisions.
• Maintain auditable records of source footage access, model configuration, transformations, corrections, uncertainties, and output limitations when results are used beyond experimentation.

XSkills safety adaptation - required failure responses

Source attribution

• Source 1: creator post, https://x.com/zostaff/status/2044921347701092752.
• Source 2: supplied linked article excerpt, https://x.com/i/status/2044921347701092752#x-article-1. Its supplied excerpt begins “Complete Technical Guide: From Data Collection to a Working Model” and does not establish additional implementation details used in this skill.

Independently compiled by XSkills from the supplied sources. zostaff did not author or review this skill. Attribution does not imply endorsement.