Case study Built at Veritone
SRT/HLS Stream Ingestion Engine.
A production recorder for live broadcast streams built to run around the clock, unsupervised, for days at a time.
- Built at
- Veritone
- Stack
- Python · FFmpeg · SRT · HLS · AWS S3 · Kubernetes
- Ran
- 24/7. Longest continuous run on SRT: 53.8+ hours, no drift.
- Output
- 5-minute MP4/TS segments to S3
Overview
The problem and my role.
The problem
Live broadcast streams had to be recorded around the clock for 24/7 processing at Veritone. They arrived over SRT or HLS, and every recording had to be cut into clock-aligned segments and delivered to S3 without anyone watching.
My role
I architected the engine: Python and FFmpeg, running on Kubernetes. SRT or HLS in, segments cut on clock boundaries, and automated delivery to S3.
Requirements
What it had to get right.
Broadcast-grade quality
Built for professional live TV workflows. SRT brings low-latency UDP transport with packet-loss recovery (ARQ retransmission); HLS brings CDN-friendly HTTP delivery. Both run through one shared protocol abstraction.
Recovery in layers
A 999-retry loop with exponential backoff, three layers of audio corruption detection (AAC decoder errors, timestamp discontinuities, file-size checks) and rate-limited auto-restart.
An engineer’s downmix
Detects 5.1 and 7.1 surround and folds it to stereo with an FFmpeg pan filter. If the source is already stereo, it copies the audio untouched.
Architecture
Signal path.
Normalled left to right, like a patchbay.
Input
srt:// or https://*.m3u8, detected from the URL
Protocol
SRTHandler or HLSHandler behind one abstract base class
FFmpeg
Single pass: buffer, flags, encode or copy, segment
Output
5-minute MP4/TS segments to S3, fresh client per upload
Monitor
AAC errors, timestamp drift, file size; auto-restart