Ingest: Terminate, Don't Transcode

In one line: the ingest tier's job is to receive bytes, cut them in the right places, and hand them off — anything more is a fleet of GPUs you did not need.

A thousand connections that never close

Every service instinct you have is tuned for requests that begin and end. This tier has none.

A camera connects once and streams for months. There is no request boundary, no natural retry unit, and no idle period. That changes the operational shape in three ways.

Load balancing is by connection, not by request. A round-robin layer-7 balancer has nothing to balance — the connection is established once and then pinned for its lifetime. Distribution happens at assignment time, and a gateway that is unlucky in its assignment stays unlucky.

Deploys are disruptive by default. Restarting a gateway drops every camera on it. With a thousand cameras across a handful of gateways, a rolling deploy is a rolling outage unless connections drain and reassign gracefully.

Failure is sticky. A crashed gateway does not shed one request; it sheds every camera it held, all of which reconnect simultaneously. The thundering herd on recovery is a real capacity event, and jittered reconnect backoff belongs in the design.

Remux, do not re-encode

The most important decision in this tier is one to not do work.

Transcoding decodes video to raw frames and re-encodes it — changing codec, resolution or bitrate. It is expensive: real-time decode plus encode per stream, a thousand times over, permanently.

Remuxing copies the already-compressed frames into a different container without touching them. It is cheap enough to be effectively free, and it is lossless because nothing is re-encoded.

For this system, remuxing is almost always right, and the reason is the read rate from the opening lesson. A video platform transcodes because millions of viewers need a ladder of renditions. Here, the archive is watched by nearly nobody, so producing multiple renditions of everything means paying continuously to prepare footage that will be discarded unwatched.

The last row is the honest cost. If a client cannot decode H.265, something has to convert it — but that something now runs on the tiny slice of footage someone actually opened, not on all of it. Transcode lazily and cache the result briefly, because the same incident often gets watched a few times in an afternoon.

Cutting the stream

The gateway's real work is turning a continuous RTP flow into discrete, addressable objects.

Segments are written as fragmented MP4 in the CMAF style rather than the older MPEG transport stream. The reason is practical: one packaging produces objects that both HLS and DASH players can consume, so you package once instead of maintaining two parallel sets of the same footage. For a system where storage is the dominant cost, storing footage twice to satisfy two protocols is exactly the kind of thing to avoid.

Each segment must begin on an IDR frame, which makes the algorithm a wait rather than a timer:

accumulate frames
when (elapsed >= target_duration) and (next frame is IDR):
    close segment, write it, start the next

Note the ordering. The target duration is a floor, not a deadline — you close on the first keyframe after the target, so actual segment lengths vary with the camera's GOP. Any index built on top must therefore store real start and end times per segment rather than assuming uniform duration. Designs that assume fixed-length segments produce playback that drifts.

Two segment lengths, one stream

The estimation lesson showed segment length pulling in opposite directions: short for latency, long for request cost and index size. The resolution is to stop treating it as one decision.

The archive gets long segments because nothing about footage nobody is watching is latency-sensitive. The live path gets short ones, and only exists while someone is actually watching. Same inbound stream, two outputs, and the expensive one is transient.

When the write path slows

Ingest cannot apply backpressure to a camera in any meaningful way. The camera is not a well-behaved producer that will wait — it is a device with a small buffer and a real-time source. Push back and it discards frames, or drops the session and reconnects.

So the gateway needs a policy for storage being slow or unavailable, decided in advance:

• Buffer locally, to a bounded local disk queue, and drain when the write path recovers. This is the first line and handles the common case of a transient blip.
• Shed deliberately when the buffer fills. Drop the substream before the main stream; drop lower-priority cameras before critical ones. A stated priority order is the difference between graceful degradation and arbitrary loss.
• Record the gap explicitly. Whatever is lost must produce a gap record in the index. Silent loss is the worst outcome in this system, because the footage appears to exist until someone looks for it.

That last point is the one to say out loud. Every other system in the course treats data loss as a failure to avoid; this one treats unrecorded loss as the failure, because an operator who knows footage is missing can act, and an operator who does not know assumes they have it.

Next: the split that keeps petabytes of media out of the infrastructure meant for events.