How it works
The path a frame takes from OBS through the freezes buffer and out to your platform.
The pipeline
OBS ──▶ ingest ──▶ delay buffer ──▶ egress ──▶ platform
│
▼
rolling historyEvery stage runs on your machine. Nothing about the stream is sent anywhere except the platform you were already streaming to.
Ingest
freezes listens on 127.0.0.1:1935 and speaks enough RTMP to look like a normal ingest server:
the handshake, the connect and publish command exchange, and the chunk stream that carries
audio, video and metadata messages.
It does not authenticate. Anything that can reach the port can publish, which is why it binds to loopback rather than every interface.
Delay buffer
Incoming messages are appended to a rolling history rather than forwarded straight away. What has already gone out is kept too, because that is what a delay is taken by rewinding into. The whole history lives in memory and is gone when the process exits: at 6000 kbps ten minutes of it is roughly 450 MB, and it is capped so a stream that outruns the budget drops its oldest material rather than the machine.
Two pointers matter: the write head, which is wherever OBS has got to, and the read head, which is the moment being sent to the platform. The delay is simply the distance between them. Changing the delay moves the read head.
Egress
A second RTMP connection runs outward to the platform, using the key you gave the panel. It republishes from the read head on its own clock, rewriting timestamps so they stay monotonic across a cut.
That rewriting is the part that has to be exactly right. Platforms will drop a stream whose timestamps jump backward or leap forward, so every seek has to produce a continuous sequence on the far side even though the source material was cut.
Why cuts land on keyframes
Video frames are not independent. A keyframe stands alone, but the frames after it are stored as differences from what came before. Start decoding from the middle of that run and you get garbage until the next keyframe arrives.
So the read head can only be moved to a keyframe boundary. With OBS on a two second keyframe interval, that is the granularity of every delay change, and it is why a requested change of exactly thirty seconds may actually land at twenty-nine or thirty-one.
What this costs
Adding delay means the read head moves backward, so viewers see a moment they have already been shown, or a held picture while the gap opens. Removing delay means it moves forward, so viewers skip a moment they never saw.
There is no arrangement of buffers that avoids this. See Delay modes for how freezes spends that cost as cheaply as it can.