The AWS Stack Behind Every World Cup Highlight You Watch La pile AWS derrière chaque résumé de Coupe du Monde que tu regardes

Someone scores a goal at MetLife Stadium. Before the stadium PA finishes its reverb, a highlight clip is already being transcoded, tagged, and pushed to 40 million phones. That is not magic — it is a pretty elegant AWS pipeline that Fox Sports and its broadcast partners have been quietly building since the 2022 Qatar cycle and scaled hard for 2026.

Quelqu'un marque un but au MetLife Stadium. Avant que la sono du stade finisse de résonner, un clip est déjà en cours de transcodage, étiqueté et envoyé sur 40 millions de téléphones. Ce n'est pas de la magie — c'est un pipeline AWS assez élégant que Fox Sports et ses partenaires de diffusion construisent discrètement depuis le cycle Qatar 2022 et ont mis à l'échelle pour 2026.

Let us walk through it service by service.

Parcourons-le service par service.

Stage 1 — Live Ingest with Elemental MediaConnect Étape 1 — Ingestion en direct avec Elemental MediaConnect

The raw broadcast feed from each of the 16 2026 venues comes in over dedicated fiber, typically as SMPTE 2110 or compressed JPEG 2000. AWS Elemental MediaConnect is the first thing that touches it inside AWS. Think of MediaConnect as a managed, low-latency transport layer — it takes the incoming broadcast signal, applies redundant paths (primary + failover), and distributes the stream to downstream consumers without you babysitting SRT tunnels at 2am.

Le signal brut de chacun des 16 stades de 2026 arrive par fibre dédiée, généralement en SMPTE 2110 ou JPEG 2000 compressé. AWS Elemental MediaConnect est le premier service à le toucher dans AWS. Considérez MediaConnect comme une couche de transport gérée et à faible latence — il prend le signal entrant, applique des chemins redondants (principal + basculement) et distribue le flux aux consommateurs en aval sans que vous ayez à surveiller des tunnels SRT à 2h du matin.

From MediaConnect, the stream forks: one path goes to MediaLive for the main broadcast output, another goes to a parallel analysis pipeline — the one we actually care about here.

Depuis MediaConnect, le flux se divise : un chemin va vers MediaLive pour la diffusion principale, un autre vers un pipeline d'analyse parallèle — celui qui nous intéresse vraiment ici.

Click to zoomCliquer pour zoomer

Stage 2 — Event Detection: Vision + Audio Working Together Étape 2 — Détection d'événements : vision et audio en tandem

This is where it gets interesting. The analysis branch runs two detection systems in parallel, and the pipeline only fires a clip when both agree.

C'est ici que ça devient intéressant. La branche d'analyse exécute deux systèmes de détection en parallèle, et le pipeline ne déclenche un clip que lorsque les deux sont d'accord.

Visual detection via Rekognition Video Détection visuelle via Rekognition Video

The analysis stream is segmented into short chunks (typically 2–5 seconds) and pushed through Amazon Rekognition Video. Fox Sports has trained custom labels on top of Rekognition's base model to detect sport-specific events: a player raising both arms (goal celebration), a referee reaching into a pocket (card), players clustering in the penalty area (set piece), and net movement (the dead giveaway). Rekognition returns a confidence score and a timestamp for each detected label. These hit an SQS queue.

Le flux d'analyse est segmenté en courtes tranches (généralement 2 à 5 secondes) et traité par Amazon Rekognition Video. Fox Sports a entraîné des étiquettes personnalisées sur le modèle de base de Rekognition pour détecter des événements spécifiques au sport : un joueur levant les deux bras (célébration de but), un arbitre fouillant dans sa poche (carton), des joueurs se regroupant dans la surface (coup de pied arrêté) et le mouvement du filet (l'indice imparable). Rekognition renvoie un score de confiance et un horodatage pour chaque étiquette détectée. Ces données atterrissent dans une file SQS.

Audio detection via custom ML on the raw feed Détection audio via ML personnalisé sur le signal brut

Crowd noise is processed separately — a custom model running on an EC2 GPU instance (g4dn family) analyzes the audio track for crowd roar patterns. Crowd noise at a goal is spectrally distinct from ambient stadium noise, and the model is trained to spike on it within about 1.5 seconds of onset. The audio signal alone would produce too many false positives (near-misses also get roars), which is why both systems need to agree within a 4-second window before anything gets clipped.

Le bruit de la foule est traité séparément — un modèle personnalisé tournant sur une instance EC2 GPU (famille g4dn) analyse la piste audio à la recherche de patterns de rugissement. Le bruit de la foule lors d'un but est spectralement distinct du bruit ambiant du stade, et le modèle est entraîné à le détecter en environ 1,5 seconde. Le signal audio seul produirait trop de faux positifs (les occasions manquées déclenchent aussi des cris), c'est pourquoi les deux systèmes doivent être d'accord dans une fenêtre de 4 secondes avant qu'un clip soit découpé.

Stage 3 — Clip Extraction and Metadata Storage Étape 3 — Extraction du clip et stockage des métadonnées

When the dual-confirmation Lambda fires, it needs to clip the right segment from the buffer. The live stream is continuously written to S3 as HLS segments — this is your rolling buffer. The Lambda back-calculates from the confirmed event timestamp, grabs the N seconds before (for context) and M seconds after (for celebration), and stitches those segments into a highlight clip. The clip gets pushed to a dedicated S3 prefix under the match ID.

Quand la Lambda de double confirmation se déclenche, elle doit découper le bon segment du buffer. Le flux en direct est continuellement écrit dans S3 sous forme de segments HLS — c'est votre buffer glissant. La Lambda recalcule à partir de l'horodatage de l'événement confirmé, récupère les N secondes avant (pour le contexte) et M secondes après (pour la célébration), et assemble ces segments en un clip de résumé. Le clip est envoyé vers un préfixe S3 dédié sous l'identifiant du match.

Event metadata — match ID, minute, team, player, event type, confidence scores, clip S3 URI — gets written to DynamoDB. The table is keyed on match_id (partition) + event_timestamp (sort), which makes it trivial to query all events for a given match in order. DynamoDB Streams then propagates the new item to downstream subscribers: the highlights API, the editorial dashboard, and the social publishing queue.

Les métadonnées de l'événement — identifiant du match, minute, équipe, joueur, type d'événement, scores de confiance, URI S3 du clip — sont écrites dans DynamoDB. La table est indexée sur match_id (partition) + event_timestamp (tri), ce qui rend triviale la requête de tous les événements d'un match dans l'ordre. DynamoDB Streams propage ensuite le nouvel élément aux abonnés en aval : l'API des résumés, le tableau de bord éditorial et la file de publication sociale.

Click to zoomCliquer pour zoomer

Stage 4 — Delivery via CloudFront Étape 4 — Distribution via CloudFront

The highlight clips in S3 are served through CloudFront. Nothing exotic here — standard S3 origin with a short TTL (30–60 seconds for the first few minutes of a fresh clip, then longer as traffic normalizes). What matters is the edge node coverage: CloudFront has 450+ PoPs globally, which means a fan in Guadalajara and a fan in Lyon are both pulling from a local cache, not hammering the same S3 bucket. For a tournament where 60+ matches happen over a few weeks, the traffic spikes are predictable enough that you can pre-warm the most likely edges before kickoff.

Les clips de résumés dans S3 sont servis via CloudFront. Rien d'exotique ici — origine S3 standard avec un TTL court (30 à 60 secondes pour les premières minutes d'un clip frais, puis plus long à mesure que le trafic se normalise). Ce qui compte, c'est la couverture des nœuds périphériques : CloudFront a plus de 450 PoPs dans le monde, ce qui signifie qu'un fan à Guadalajara et un fan à Lyon tirent tous deux d'un cache local, sans marteler le même bucket S3. Pour un tournoi où 60+ matchs se déroulent sur quelques semaines, les pics de trafic sont suffisamment prévisibles pour pré-chauffer les edges les plus susceptibles d'être sollicités avant le coup d'envoi.

What the Other Broadcasters Are Doing Ce que font les autres diffuseurs

Fox Sports is not alone in this space. The BBC's iPlayer team has deployed AI-assisted editorial tools that surface candidate clips to human editors rather than fully automating publish — a more conservative approach that reflects the BBC's editorial standards. Telemundo and NBC's Spanish-language coverage have integrated AI commentary assist: natural language generation that drafts a Spanish-language audio summary of each event, which a human presenter then delivers (or sometimes the AI does, flagged as synthetic). The underlying clip pipeline is similar to Fox's; the differentiation is what you do with the clip once you have it.

Fox Sports n'est pas seul dans cet espace. L'équipe iPlayer de la BBC a déployé des outils éditoriaux assistés par IA qui présentent des clips candidats à des éditeurs humains plutôt que d'automatiser entièrement la publication — une approche plus conservatrice qui reflète les standards éditoriaux de la BBC. Telemundo et la couverture en espagnol de NBC ont intégré une assistance à la commentary par IA : génération de langage naturel qui rédige un résumé audio en espagnol de chaque événement, qu'un présentateur humain délivre ensuite (ou parfois l'IA le fait, signalé comme synthétique). Le pipeline de clips sous-jacent est similaire à celui de Fox ; la différenciation réside dans ce que vous faites du clip une fois que vous l'avez.

Click to zoomCliquer pour zoomer

So What? The Pattern That Transfers Et alors ? Le pattern qui se transfère

If you are a cloud architect and you have made it this far, you have just read a textbook real-time event processing pattern: continuous stream ingest, parallel multi-modal detection, dual-confirmation gate, buffer-backed clip extraction, metadata to a time-series-friendly NoSQL store, CDN delivery. Swap the domain and this is also a fraud detection pipeline, a factory floor anomaly system, or a live sports betting data feed. The services change at the margins — maybe Kinesis Data Streams instead of SQS, maybe Timestream instead of DynamoDB for the time-series query patterns — but the shape is the same. The World Cup just happens to be a very visible stress test for it.

Si vous êtes architecte cloud et que vous avez lu jusqu'ici, vous venez de lire un pattern classique de traitement d'événements en temps réel : ingestion continue du flux, détection multimodale parallèle, porte de double confirmation, extraction de clip depuis un buffer, métadonnées vers un store NoSQL adapté aux séries temporelles, distribution CDN. Changez le domaine et c'est aussi un pipeline de détection de fraude, un système d'anomalie sur un plancher d'usine, ou un flux de données pour paris sportifs en direct. Les services changent à la marge — peut-être Kinesis Data Streams plutôt que SQS, peut-être Timestream plutôt que DynamoDB pour les patterns de requêtes temporelles — mais la forme est la même. La Coupe du Monde est juste un test de charge très visible pour ça.

The next time a goal goes in and your phone buzzes before you have processed what you just saw on screen — that is the pipeline. Running at scale. In a stadium. During the most-watched sporting event on the planet.

La prochaine fois qu'un but est marqué et que votre téléphone vibre avant même que vous ayez réalisé ce que vous venez de voir à l'écran — c'est le pipeline. Tournant à grande échelle. Dans un stade. Pendant l'événement sportif le plus regardé sur la planète.

---

← Back to Articles ← Retour aux articles