masqueradarr becomes the origin

A rewriting proxy still shows you their timeline

Everything on the Video proxy engine page describes a rewriting proxy. The upstream playlist is fetched, its URIs are rewritten to point back through masqueradarr, and the rest is passed through. That hides hostnames — which is most of what people want from a proxy — but it leaves two things unsolved.

First, the client is still looking at the provider's timeline: their media sequence, their #EXT-X-KEY, even their vendor tags. You are relaying someone else's document. Second, every viewer is a separate trip upstream. Two people watching the same channel means two full pulls from the provider — the same bytes, fetched twice, because there was nowhere to put them.

One ingest, a ring of pairs, two renderers

The design has a left half and a right half that run at different rates, and that is the whole claim. Everything on the left happens once per channel. Everything on the right reads the same cached bytes, as many times as there are viewers. The engine names them Side-1 (ingest, tagged iop) and Side-2 (serve, tagged oop) — and it tags every log line and every telemetry frame with which side it came from.

There is still exactly one ring. What changed is what an entry holds: on a demuxed source a single entry carries the video segment and its audio partner, so the two published playlists are identical by construction and a renderer can never serve half a pair.

originEnabled × outputFormat

The new switch is orthogonal to the one you already have. outputFormat decides the shape handed to the player; originEnabled decides where the bytes come from. Every combination is valid.

What the player actually receives

In origin mode the manifest contains no provider host, path, session id or query; no #EXT-X-KEY; no vendor tags; no proxy hop URLs. It is short enough to read in full:

# the authored media playlist — every line is ours
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:6          # ceil() of the longest EXTINF in the window, min 1
#EXT-X-MEDIA-SEQUENCE:1042     # the seq of the ring's oldest held entry
#EXT-X-DISCONTINUITY-SEQUENCE:3 # splices that have already left the window
#EXT-X-PROGRAM-DATE-TIME:2026-08-05T20:14:07.812Z
#EXTINF:5.005,
/api/ext/v1/pluto/o/<enc-entry>/0-1042.ts?token=…&pl=…
#EXTINF:5.005,
/api/ext/v1/pluto/o/<enc-entry>/0-1043.ts?token=…&pl=…
#EXT-X-DISCONTINUITY  ← only at a real splice (see below)
#EXTINF:4.984,
/api/ext/v1/pluto/o/<enc-entry>/0-1044.ts?token=…&pl=…

• No #EXT-X-ENDLIST and no #EXT-X-PLAYLIST-TYPE, so any standard player treats it as a live sliding window.
• The window is the ring. There is no separate window length — the playlist lists whatever the ring currently holds. That means originRingMb is simultaneously the RAM budget and the advertised live-window length.
• Every segment line carries the token. These paths are guessable by construction — a source, an entry, and two integers — so the token on each line is what keeps per-account governance meaningful. It is not a separate gate.
• #EXT-X-PROGRAM-DATE-TIME is a real timestamp, emitted at the head of the window from that entry's ingest wall-clock — and again after every discontinuity, so a player never has to carry one anchor across a splice. It discloses when we ingested, not who we ingested from — but it is not nothing, and it is the only field in the document that isn't a counter.
• On a demuxed source this is not what the entry URL returns. It answers with a small master we author instead, over two playlists of exactly this shape — one for video, one for audio, identical apart from the segment URIs.
• Two numbers in the path. <generation>-<seq> is not redundant. That is its own section.

One per channel, refcounted, self-reaping

An ingest is keyed by source + entry URL — not by viewer, not by token, not by playlist. Two people watching the same channel from different accounts and different playlists share exactly one ingest. Starting one is idempotent: whichever request gets there first spawns the task, and everyone after that just increments a subscriber count.

When it stops — and the 30-second grace

There is no reaper task. The ingest watches itself: every 5 seconds it asks whether it has zero subscribers and nothing has read the ring for 30 seconds. If both hold, it stops — waking every parked reader, removing its own registry entry, and reporting a final closed.

When the audio arrives on a rendition of its own

Some providers — pluto on every device cohort — publish no muxed variant at all. Every #EXT-X-STREAM-INF defers its audio to a separate #EXT-X-MEDIA rendition with its own URI=. Following the variant alone would ring, and serve, video only: a picture with no sound. The engine prefers a variant whose audio is muxed in wherever one exists, and only calls a source demuxed when every variant defers.

On such a source the ingest rings the pair. One ring entry holds the video segment and its audio partner — not a second queue alongside the first. Holding both on one entry is what makes the two published playlists identical by construction: same #EXT-X-MEDIA-SEQUENCE, same discontinuity sequence, same #EXT-X-PROGRAM-DATE-TIME anchors, one eviction. A renderer cannot serve half a pair, because half a pair is not a thing the ring can hold.

The pid that moves, and the demuxer that doesn't follow

An ad creative is transmuxed just-in-time, by different machinery than the programme around it, and it arrives with its own arbitrary PSI. On live pluto the video PID itself moves across a single pod — 258 → 256 → 258. A demuxer does not follow an elementary stream to a new PID: it keeps rendering the one it latched onto and registers the new one as a stream nothing is displaying. The picture freezes until the PID happens to come back.

This is worth being precise about, because it is not the problem #EXT-X-DISCONTINUITY solves. That tag describes a timeline break. This is a stream identity break, and the only fix is to stop the identity from changing. So every ingested segment is republished onto one timeline with canonical pids:

RAM, not disk — and a cap that can be overruled

The ring is a queue of decrypted entries in memory, oldest first. It is never written to disk. Each entry holds six things: our sequence number, the duration, the plaintext video bytes, the paired audio bytes (on a demuxed source), whether a discontinuity opens before it, and the wall-clock at ingest. That is all a renderer ever needs — which is why neither renderer has to know anything about the upstream.

It is bounded per channel by originRingMb (default 25 MiB, roughly a minute at 3.3 Mbps). On each push, the oldest entries are evicted until the total is back under the cap — unless doing so would leave fewer than three. The floor always wins.

Both lanes count against the cap. The cap is a RAM budget and the pair is what occupies the RAM, so on a demuxed source a given originRingMb buys a marginally shorter window than it does on a muxed one — on pluto the audio rendition runs about 3 % of the video's bitrate, so the difference is small but real. It is the honest reading, and the one the floor-beats-cap warning below is judging.

Why <generation>-<seq> and not just a sequence

Our sequence number counts segments and never goes backwards for the life of an ingest — not across a mirror rotation, not across a failover. That matters because a backwards #EXT-X-MEDIA-SEQUENCE stalls players. But a failover onto a different upstream does invalidate the ring: those bytes came from somewhere else. So the ring gets a second counter.

Two renditions do not concatenate — so they are woven

HLS can publish a pair as two playlists. Raw TS is one socket, and two transport streams cannot simply be glued end to end. So outputFormat: 'ts' on a demuxed source used to decline — which meant the one source shape local origin exists for was exactly the shape raw TS could not serve.

It is now folded into one authored program on the way out, off the same ring entries the two HLS playlists are rendered from. The muxer is small because pairing and normalization already did the hard part — one shared clock, disjoint canonical pids, correct per-pid continuity counters — so the weave is transport-layer only: no decode, no re-encode, no timestamp rewriting.

Cutting a socket that has no playlist

A direct or hdhomerun upstream arrives as one endless socket with no playlist at all. There is nothing to poll and nothing that says where a segment ends. So the engine finds the boundaries itself — without an ffmpeg, and without decoding a single frame.

This is a content decision, not a per-adapter one: the engine sniffs what the entry actually returned. Anything that doesn't start #EXTM3U is segmented locally, whatever source it came from.

AES-128 is decrypted at ingest — and what still declines

On the rewriting path, an encrypted source is relayed still encrypted: the player fetches the key through us and does the work. Under local origin the engine decrypts at ingest instead, so the ring holds plaintext and the authored manifest has no key line at all. It is pure Rust (no system OpenSSL), using hardware AES where the CPU has it.

Three triggers, and a fourth that was deleted

Ad-stitched sources splice. Where the engine cannot absorb the splice, the authored playlist emits #EXT-X-DISCONTINUITY — and that is in-spec output, not a leak. It says nothing about where the stream came from, and every player handles it. “Clean” here means no visible origin, no encryption and no hop URLs; it does not mean one unbroken timeline.

Detection and publication are two separate decisions, and it is worth keeping them apart. Detection has exactly three triggers, each independently sufficient:

Publication is the second decision, and with spliceNormalize on it usually goes the other way. Where the splice was genuinely absorbed onto an existing timeline, no tag is emitted at all — there is no longer a break to describe. Where normalization declined, or the segment opened a fresh anchor, the upstream's signal is published as before. The iop log names which happened — a published splice logs discontinuity (Tag), an absorbed one logs splice ABSORBED (Tag) and says why: rebased onto one timeline, no tag published.

Ingress and egress stopped being the same number

This is the part that changes how you read every existing screen. Once one ingest feeds N viewers, “the channel is stuttering” has two possible causes — the ingest can't keep up, or serving can't keep up — and they need telling apart. So every log line and every telemetry frame is tagged with which side produced it: iop for input operations (resolve, poll, fetch, decrypt, ring push and evict), oop for output ones (manifest render, segment serve, TS concat).

What the iop frame now carries

The per-channel ingest frame grew well past “how many bytes”. Four of its fields answer questions the earlier ones could not:

Where the two sides show up in the app

Three controls, Default or per playlist

All three knobs live in the proxyconfigs subsystem alongside the rest of the engine's settings, so each can be set globally or overridden for a single playlist. They sit deliberately directly above Output format, because local origin changes what that setting means. The two beneath Local origin are greyed out while it is off.

What to know before you switch it on