Streaming engines

The two engines compared

	Remux engine	Pass-through engine
Cold start, join to first packet	~4.4 s	~1.9 s
Full 1316-byte datagrams	85%	100%
CPU per channel	~5% of a core	~15%
RAM per channel	~72 MB	~23 MB
Channels on a 2 GB appliance	~16	25+
PIDs and service ID	Rewritten	Original, preserved
Audio tracks delivered	One	All, with ISO-639 language tags
Subtitles and teletext	Dropped	Passed through
Source-side packet loss	Hidden	Reported faithfully
Constant bitrate padding	Yes	No
fMP4/CMAF HLS source	Yes	No

Which to choose

The pass-through engine is the default and is the right answer for almost everything. It uses about a third of the memory, which is what sets the channel count on a 2 GB appliance; it reaches first picture in roughly half the time, which is what a viewer experiences as channel-change speed; every datagram it sends is a full 1316 bytes; and every audio language in the source arrives at the television with its language tag intact. It does less, and doing less is why it does it better.

Choose the remux engine when one of these is true:

• The HLS origin publishes fMP4/CMAF segments. The pass-through engine’s HLS reader handles MPEG-TS segments only. This is not configurable.
• The source is RTMP. RTMP is not supported on the pass-through engine at all.
• A downstream device requires constant bitrate on the UDP output. Only the remux engine can null-pad the stream to a fixed rate. Some older set-top boxes and some RF modulators need this; most modern equipment does not.

Its higher CPU cost is real but rarely the binding constraint: memory runs out first on these appliances. Plan capacity against RAM.

Why the remux engine delivers only one audio track

The pass-through engine does not demux, so every audio PID in the source — along with the original PMT and its ISO-639 language descriptors — arrives downstream untouched. A viewer can select a language on the television because the television can see that the languages are there.

The remux engine builds a new transport stream. Its argument list copies audio rather than re-encoding it, but sets no explicit stream mapping, so default stream selection applies: one video stream, one audio stream, everything else discarded. The track you get is whichever the source lists as its best candidate, and it is the only one.

Carrying all audio tracks is a single option away, and it is deliberately not enabled. It would raise the output bitrate of every channel — audio tracks are small but a six-language feed is not free on a multiplex — and it would change the transmitted stream for every channel already in service, which is not something to do globally on an appliance somebody commissioned last year. A per-channel opt-in is roadmap.

Neither engine can create what the source lacks

If the origin carries one audio track, no engine setting produces a second. This is also why the demuxed-ladder guard on resolution profiles matters: a ladder whose audio lives outside the video variants has no audio to pass through at all once a single video variant is selected.

Why the remux engine hides source loss

Building a new transport stream means re-stamping continuity counters. Every packet leaving the appliance therefore carries a correct, unbroken counter sequence, regardless of what arrived. Gaps introduced upstream — by the origin, by the internet path, by a flaky encoder — become invisible the moment they pass through.

That is useful in production, because a downstream analyser stops alarming on faults it cannot act on. It is actively misleading during a fault investigation. If you are trying to establish whether an upstream feed is losing packets, put the channel on the pass-through engine first, or you will be measuring the quality of your own repair work rather than the quality of the feed.

The pass-through engine reports loss faithfully for the same reason it preserves PIDs and audio: it does not rebuild anything.

Metrics differ by engine

Frames per second, playback speed and encoder-reported bitrate are read out of the remux engine’s own progress output. The pass-through engine never decodes video, so it does not know the frame rate and has no concept of playback speed. Those figures do not exist for it.

On a pass-through channel those tiles read n/a. That is correct and expected, not a fault and not a sign the channel is unhealthy.

The engine-agnostic signal is wire bitrate, measured by packet capture on the output interface. It is the only liveness measurement that works identically on both engines, it measures what actually left the network port rather than what a process claims it sent, and it is the one to trust. See Monitoring and metrics.

Do not key external monitoring on frames per second or playback speed

Any watchdog, alert rule or dashboard threshold built on those values will fire continuously against pass-through channels, because the values are absent rather than zero — and a rule that treats absent as zero will restart perfectly healthy channels indefinitely. This has happened more than once in the field, and in both cases the symptom looked like an engine bug rather than a monitoring bug. Gate such checks on the engine in use, or key them on wire bitrate instead.

Service naming

On the pass-through engine, the channel name is written into the SDT of the outgoing stream, so a television scanning the multicast group or the DVB-C multiplex shows the name you configured rather than whatever the origin happened to embed.

The remux engine does not carry service naming. A channel on the remux engine will present whatever service name results from the remux, which is generally not the name in the Castmux interface. If the name shown on the television matters — and in a hotel or hospital it usually does — that is a reason to prefer the pass-through engine.

Setting the engine

There are two levels:

Global default

Set in Settings. It applies to every channel that does not override it, including channels added later.

Per-channel override

Set on the channel. Use it for the exceptions — the fMP4 origin, the RTMP feed from the local encoder, the one channel whose downstream modulator insists on constant bitrate.

A channel with no override displays the inherited value, marked as inherited, so it is always visible whether the engine shown was chosen for that channel or is following the global setting. Changing the global default changes every inheriting channel at once; channels with an override are unaffected.

Changing the engine restarts the channel

The engine is chosen when the channel starts, so switching it takes effect on the next start and the channel is restarted to apply it. Viewers see the cold-start delay for that engine — about 1.9 s onto pass-through, about 4.4 s onto remux. Switching the global default restarts every inheriting channel, so do it during a quiet period rather than in the evening.