Stream copy¶

One signal is often needed in several forms: as is, for the archive and internal monitoring, and processed, for viewers; open for some and encrypted for others. Receiving it twice is not always possible: an SRT encoder answers one caller, a satellite receiver hands out one stream. The Copy source reads another stream of the same streamer inside the process — no second connection to the source and no network loop. The copy is a stream of its own, with its own settings.

What the copy receives¶

The copy reads the target stream after all of its processing — transcoder, alignment and segmentation — and sees exactly what the target serves to viewers, with the same timestamps. The fragment boundaries the target cut the stream at arrive together with the frames: the copy cuts at the same places, and the archives of the two streams consist of identical segments.

Nothing else is inherited. The copy is a separate stream with its own tabs: transcoder, archive, playback protection, delivery and placement are configured on it anew and do not affect the target. This way one received signal gets as many independent processings as needed, while the source stays connected once.

Set up a copy¶

1. Create the stream that will be the copy — for example, arena-mobile next to the receiving stream arena.
2. On the Sources tab click + Add source and choose the Copy protocol.
3. In the Target stream (this node) field enter the name of the stream to read: arena.
4. Save. The source indicator turns green as soon as the target serves frames; the card under the source shows the status and bitrate, like for any other source.

In the stream list the target and the copy are two ordinary running streams.

The target's settings do not change: it does not need to know about its copies, and there can be several of them.

An on-demand target¶

If the target stream's Start mode is On demand, the copy starts it itself, like a viewer would: the target starts together with the copy and runs while the copy reads it. Once the copy is stopped or deleted, the target goes idle by its own no-viewers timeout.

The target in a cluster¶

The copy reads only a stream of its own streamer: the signal never crosses the network between machines. The layouter places every stream separately and knows nothing about the link between a copy and its target, so keeping both on one streamer is up to you — with a namespace or a tag. The simplest way: give the target and the copy the requirement required_<tag>, and the tag itself to exactly one streamer.

If the target is placed on another streamer, the copy's source stays in error: the stream waits and connects by itself as soon as the target appears on its machine.

What is not allowed¶

Validation on save rejects two configurations and highlights the target stream field:

• A stream reads itself. The copy would wait for the frames it is supposed to produce.
• A chain of copies closes into a ring. a reads b and b reads a: neither has a source. A chain without a return — a copy of a copy — is allowed.

If the copy does not run¶

• The source is dead, the target is not found. Check the name in the target stream field and the placement: the target must run on the same streamer as the copy.
• The target is stopped. The copy's source is in error, the stream waits. As soon as the target serves frames again, the copy connects by itself — nothing needs changing.
• Input errors are growing. The copy cannot keep up with the target and some frames are lost: the streamer is overloaded. See source diagnostics and the streamer's load.