Video Input Requirements

Required Input Characteristics

Your SRT or HLS input should meet the following requirements:

Audio stream present and commentary present are not the same requirement:

The stream must contain an audio track for SRT ingest.
The audio track must include clear spoken commentary for highlight detection.

A stream can ingest successfully with audio but still produce no highlights if the audio is only crowd/ambient noise. See No Highlights Detected for more troubleshooting tips.

Requirement	Why it matters
Video codec: H.264 / AVC	The service supports H.264 only. Other video codecs (HEVC, AV1, VP9) are not supported — transcode your feed to H.264 before streaming.
Include both video and audio streams	SRT ingest expects both streams (`-map 0:v` and `-map 0:a`). Audio-less streams will fail ingest.
Include clear commentary audio	Event detection relies on speech context. Crowd-only/noise-only audio is not commentary and won’t produce highlights.
Commentary in a supported language	Language is detected automatically, but the commentary must be in one of the 50 supported languages.
Commentary clearly audible in the mix	If crowd noise overpowers commentary or commentary is mixed at a very low level, detection accuracy will suffer.
Minimum bitrate for portrait cropping: 3000 kb/s	Lower bitrates significantly reduce portrait crop quality and tracking stability.

Video must be H.264 / AVC. Other video codecs are not supported. AV1 and VP9 in particular cannot be reliably carried over MPEG-TS and will fail ingest with no usable video stream. If your source is anything other than H.264 — for example a re-streamed YouTube or social feed, which is frequently delivered as VP9 or AV1 — transcode it to H.264 before streaming (use -c:v libx264 instead of -c copy).

Network / Connectivity

Each task is ingested by a dedicated worker. For srt_listener, the srt_url returned by create-task contains the per-task host and encryption passphrase — stream to it exactly as returned. For hls_pull, Narrative reads the manifest from source_url; no inbound URL is returned. HLS EVENT manifests may retain substantial history, so choose source_start.mode: "live_edge" when processing should begin with newly published media. See HLS Start Position for offset and program-date-time starts. Configure your encoder as follows:

Setting	Value
Mode	SRT caller
Protocol / port	UDP 9000
Host / passphrase	From the `srt_url` returned by create-task — use it verbatim.

Stream to the srt_url returned by the API exactly as-is. It contains the per-task host and encryption passphrase and is valid only for that task — don’t rebuild or modify it.

Sport-Specific Notes

MMA

MMA broadcasts have a few characteristics that are worth accounting for when you stream:

Long walkouts. Each fighter’s walkout sequence — announcer call, entrance music, commentator discussion — can run 60–120 seconds or more. These are detected as first-class events (fighter_walkout) and kept as full clips rather than trimmed. Don’t cut away during walkouts if you want them captured.
Multi-fight cards. A single stream often contains an entire promotion event (5+ fights). Fights are delineated automatically based on walkouts and finishes — no configuration needed. See Multi-Fight Cards for the resulting metadata.
Ring announcer vs commentary audio. The formal post-fight declaration (“the winner by knockout…”) and judges’ scorecards are ring-announcer audio, distinct from color commentary. Both should be audible in the mix for reliable finish-event detection.
Finish signal required for tko / knockout. A takedown or knockdown by itself is not a TKO; the commentary or ring announcer must make the stoppage explicit (ref waves it off, doctor stops it, etc.). This keeps mid-fight action from being mis-categorized as a finish.
1:1 square variant. Every rendered MMA highlight also produces a square (1:1) crop alongside the existing 9:16 portrait, using the same fighter-tracking trajectory. Other sports remain 16:9 + 9:16 only.

Recommended FFmpeg Mapping

Use explicit stream mapping so the ingest receives the primary video and audio tracks:

ffmpeg -re -i "INPUT.mp4" -map 0:v:0 -map 0:a:0 -c copy -f mpegts "YOUR_SRT_URL"

Explicit mapping also avoids accidentally muxing embedded thumbnail streams (for example MJPEG cover art).

Streaming From a VOD File

If you’re streaming a re-encoded MP4 (uploaded replays, test streams) rather than a live broadcast feed, the plain command above may produce segments that can’t be parsed independently. Add the following flags on the sender so each segment carries its own decoder parameter sets and PAT/PMT:

ffmpeg -re -i "INPUT.mp4" \
  -map 0:v:0 -map 0:a:0 -c copy \
  -bsf:v "h264_mp4toannexb,dump_extra=freq=keyframe" \
  -mpegts_flags "+resend_headers" \
  -pat_period 0.1 \
  -f mpegts "YOUR_SRT_URL"

These flags re-inject H.264 SPS/PPS before every keyframe and re-emit PAT/PMT periodically. They are harmless no-ops on live broadcast streams (which already carry periodic headers), so safe to include by default.

Validate Before Streaming

Check primary video bitrate:

ffprobe -v error -select_streams v:0 -show_entries stream=bit_rate,codec_name,width,height -of default=noprint_wrappers=1 "INPUT.mp4"

Check primary audio stream presence:

ffprobe -v error -select_streams a:0 -show_entries stream=codec_name,channels,sample_rate -of default=noprint_wrappers=1 "INPUT.mp4"

Introduction

Concepts

Required Input Characteristics

Network / Connectivity

Sport-Specific Notes

MMA

Recommended FFmpeg Mapping

Streaming From a VOD File

Validate Before Streaming

​Required Input Characteristics

​Network / Connectivity

​Sport-Specific Notes

​MMA

​Recommended FFmpeg Mapping

​Streaming From a VOD File

​Validate Before Streaming

Required Input Characteristics

Network / Connectivity

Sport-Specific Notes

MMA

Recommended FFmpeg Mapping

Streaming From a VOD File

Validate Before Streaming