- Footprint
- Pure Go, no CGo, no runtime dependencies. Small, fast, and plain on purpose: less is more, applied to a media server.
- SRT ingest
- Publishers push over SRT with per-stream identity and optional link encryption; through the API the server can also be asked to pull a remote source. SRT is battle-tested transport that holds up over loss, jitter and long distances.
- Normalized core
- Every input becomes one internal stream model: tracks, languages, timestamps, wall clock. Consumers never touch raw ingest.
- Codecs
- H.264 video with multiple selectable, language-tagged audio tracks: AAC-LC in both common framings, MPEG audio Layer II and III. More codecs are under consideration and will follow the roadmap's priorities.
- HLS delivery
- Standards-faithful HLS at the origin, low-latency HLS (LL-HLS) at the edges: split renditions, selectable audio, verified in real players.
- Recording
- Durable recording beside the live path: playable while still being written, a VOD at the same URL once finished, intact across restarts.
- S3 publishing
- Crash-safe publishing to S3-compatible storage. It resumes after restarts, confirms remote success before local cleanup, and does not block live delivery.
- Origin-edge
- One binary, two modes. Edges pull a cleaned transport stream on demand over the same fault-tolerant SRT and serve viewers close by, while the origin ingests, records and publishes. Every output is optional and explicitly configured.
- Topology
- A standalone, high-capacity server and an ad-hoc cluster of many origins and many edges are both first-class shapes. Preserving that freedom is a requirement weighed in every design decision.
- Stream registry
- Optional discovery for multi-origin setups: origins advertise streams, edges resolve them before pulling. Redis today, DynamoDB by design; a static setup needs no registry at all.
SRT in. HLS out.
A minimalist live media server, written in Go, for people who run infrastructure: one static binary that runs as origin or edge, one config file, and a data path that is bounded, measured, and written down.
Capabilities
Observability
Live video fails in public. The difference between a blip and an incident is how fast someone sees the problem, so visibility is treated as a deliverable in its own right.
Prometheus metrics across the pipeline, health probes that separate process trouble from stream trouble, structured logs with no secrets in them, and reference Grafana dashboards maintained together with the code. Visibility is reaction speed, and reaction speed is money.
The surface is Kubernetes-friendly out of the box: liveness and readiness probes, a clean and fast read-only status API, plain Prometheus exposition. It is a surface to build on: custom tooling and orchestration layers fit naturally, which keeps the architecture open. Self-hosted or on any cloud provider, dispergo behaves the same, because everything is built on standards rather than platforms.
Method
dispergo is built the way operators wish their vendors built things: slowly, deliberately, and in writing. Behind it are several decades of broadcast and streaming infrastructure work, and the failure modes that experience buys.
Every architectural decision is recorded with its reasoning before code lands. Every parser is tested against malformed and hostile input. Every protocol claim traces to a spec section, not folklore. Resource use is bounded everywhere: a misbehaving stream is contained, never contagious.
Every change passes the full test suite and the static analysis, formatting and build gates before it lands. A feature is called finished only after it survives all seven layers of the test strategy: unit, component, integration, compatibility against real players and real storage, fault injection, soak, and capacity measurement, with fuzzing and race detection where they bite.
Roadmap
The roadmap is solid, and it moves at a deliberate pace. Nothing lands because it is fashionable: every feature is designed twice, once as a capability and once as a part of the platform, before any of it is built. What ships is finished, and what is not finished does not ship.
Status
dispergo is alpha software. The data path from SRT ingest to edge delivery is implemented, tested and instrumented. Interfaces may still change without ceremony.
The name
dispergo is Latin, first person singular: dis + spargere, I scatter apart, I distribute. The English word broadcast is the same construction: broad + cast, to scatter seed widely, a farmer's word long before it became an engineer's.
It is also valid Italian: io dispergo, I disperse. That makes the domain dispergo.io a complete sentence, written back to front. And yes, the name ends in go.