Datasheet

A fixed address for your sources, and a full stream router behind it.

Norsk Relay sits between your sources and everything that consumes them, and does two jobs that overlap — most deployments want both:

A static ingest gateway in front of dynamic resources. Venues, cameras and contribution links push to a relay address you give out once. Encoders, recorders and monitors pull from the relay, and they can come and go — crash, move, be replaced, scale out — without the source ever noticing or being reconfigured.
A stream router, in any facility. Between ingest and egest, every stream is a declared decision: failover and operator switching, nested switches, muxes that assemble one programme from tracks carried by several feeds, track selection, and PID, programme and language mapping — all in the compressed domain, with no decode or transcode. That is as useful in a fixed facility, an OB truck or an on-premises data centre as it is in the cloud.

Around both: per-identity access control, acceptance rules, a live monitor at any point in the browser, recording, and a full audit trail.

A static gateway in front of dynamic resources

In a cloud or elastic deployment the encoder is the fragile, churny part of the chain: it decodes, transcodes, drives hardware and runs third-party code, and when it is replaced its address changes. Sources are the opposite — configured once, days ahead, by someone who is not watching your cloud. Point a source straight at an encoder and every encoder failure becomes an outage only the venue can fix.

The relay reconciles the two. It never decodes or transcodes the media it relays, so the crash surface that makes encoders fragile is absent, and it holds the address still while everything downstream of it moves. One feed in becomes as many pulls as you need — a primary and a backup encoder, a recorder, a monitor — and each consumer can be replaced without the others, or the source, noticing.

A stream router, wherever the streams are

Contribution rarely arrives in the shape its consumers need. A programme is a camera’s picture with a commentary from somewhere else; a backup feed has to take over cleanly; one consumer wants English audio only, another wants every language on its own fixed PIDs; an operator needs to cut to a different source now, and back again later. That work usually means an SDI or IP router, a transcode chain, or both — more equipment, more latency, and quality lost to every re-encode.

The relay does it on the compressed streams, as data:

Switching — primary / backup failover on policy, operator cuts that hold until the policy is resumed, pins, a slate when nothing can serve, and cuts that land cleanly on keyframes.
Composition — muxes that build one programme from tracks of several inputs, and switches nested inside them, so the picture can be cut without touching the sound.
Mapping — each link in a stream’s tree takes exactly the tracks it names and places them on the PIDs, programme and language tags the output needs; the same programme can go out again in a second layout.
Operation — every one of those decisions is visible and editable on a flow canvas, watchable at any point in the browser, recordable, and audited; the same declarations drive it from the API.

Nothing about this role depends on the cloud: run the relay on premises and it is a stream router in its own right. Run it in front of elastic encoders and the two roles reinforce each other — the router’s decisions are made once, at the fixed point every consumer shares.

How it works

venue / camera ──SRT / RIST / RTMP(S) / TS / MoQ──▶  [ Norsk Relay ]  ──SRT──▶ primary encoder
                                                          │            ──SRT──▶ backup encoder
                                                          │            ──SRT──▶ recorder / monitor
                                                          ├──▶ browser monitor (MoQ), any point in the flow
                                                          ├──▶ recordings: TS files, time-addressable store
                                                          └──▶ API, event feed, audit, metrics, operator UI

Inputs are the feeds arriving at the relay — pushed to a listener, or pulled by the relay dialling out.
Streams are the decisions about the media: which input is on air, what happens when it fails, which tracks travel and where they land.
Outputs are the connections consumers dial, each with named consumer identities. An output can be moved from one stream to another.

A stream’s source is declared as data: a single input, a failover switch between inputs, a mux that assembles one programme from tracks carried by several inputs, or another stream — nestable, so a switch can cut between a composed programme and a plain camera. The operator UI draws the same tree as a flow canvas and edits it in place.

Ingest

Protocol	Modes	Security
SRT	Listen (shared, multiplexed listeners) or pull (the relay dials a sender); bonded links on both	AES-128/256 via passphrase; per-user identity in the standard `streamid` (`#!::r=…,u=…`)
RIST	Listen or pull; main or simple profile; redundant paths	AES, SRP authentication in either direction
RTMP / RTMPS	Push; the stream key is the whole path (`rtmp://host/<key>`)	Stream key; TLS on RTMPS
MPEG-TS over UDP	Push, one port per input; SMPTE ST 2022-7 redundant path, merged hitlessly	Source-address allow-list
MoQ (Media over QUIC)	Push, namespace-routed on a shared QUIC listener	TLS

Many inputs share one SRT listener port: the streamid routes each connection to its input and chooses the passphrase that must match, so one firewall rule serves every event. SRT listeners are a declared resource with their own transport settings (latency and the like); each input names the listeners it may arrive on, and reports the latency it actually negotiated. An input can have its secrets rotated live — the new one takes effect, existing sessions keep their handshake — or revoked, which disconnects the holder. Each SRT connection runs isolated in its own engine node.

Egest

SRT pull — consumers dial the relay. Each output declares its consumers by name, each with its own passphrase, a connection limit and an alert if it is missing. A single connection of a shared identity can be kicked without touching the others.
SRT push — the relay dials a destination, plain or bonded.
Fan-out — any number of consumers per stream; a consumer that attaches before the source arrives is held and simply starts receiving when media flows.
Egest listeners — many outputs on a few shared SRT ports, declared through the API; each output can name the port it goes out on (to match a customer’s firewall), and is refused on the others. With none, each output has a port of its own.
Pass-through — no decode, no transcode: the media is routed and re-mapped, never re-encoded.

Tracks and composition

Track selection per edge — every link in a stream’s tree takes exactly the tracks it names (for example “video and just the English audio” from one input, the commentary from another), chosen by track rather than by position.
PID placement — each edge places its tracks on the PIDs, programme and language tags the output needs; a second stream can serve the same programme in a different PID layout for a consumer that wants its own map.
Muxes — one programme from tracks carried by several inputs; while a member is missing, carry the rest or hold until all are present.
Nested switches — cut the picture without touching the sound, or cut a whole composed programme to a plain camera.

Failover and switching

Primary / backup / tertiary inputs on a stream, reverting when the primary returns. A cut lands on the new source’s keyframe, honouring B-frames: no frame is ever sent without its references, and the output’s timeline never steps back — so a decoder downstream sees a clean cut, not a burst of errors. Picture and sound cut together; when a source fails, the output waits at most one GOP of the backup for its keyframe.
Switch policy — switch on loss (before the loss grace expires) or on degradation, with a hold-down to stop flapping and an optional buffer delay.
Operator cuts — make active puts an input on air and holds it there against the policy until it stops serving or the operator resumes the policy. A pin goes further: the pinned input takes back over whenever it serves again.
Slate — when no input can serve, a switch plays a slate chosen from the relay’s asset library: an MP4 uploaded once, played as it is (nothing transcodes it), and retired the moment a real input returns.
Health-driven admission — a source running ahead of real time or stalled is dropped; one that is late or lossy is flagged but kept. A reconnecting source from the same origin replaces its own stale (“zombie”) connection at once; a different origin can take over only once the incumbent has stalled for a configured time.

Acceptance rules

Decide what a source must look like before it is relayed, and reject or flag anything else with the reason recorded:

Codec policy per stream, over a supported floor of MPEG-2, H.264, HEVC, AV1 and JPEG XS video and MP2, MP3, AAC, AC-3, E-AC-3, Dolby E and Opus audio — down to profile and level.
Video — required or not, resolution bounds, allowed frame rates.
Audio — required or not, sample rates, channel layouts, languages.
Bitrate — minimum and maximum, with a dwell time.
Active windows — a stream accepts sources only inside its scheduled windows; optionally, an in-progress source is disconnected when its window closes.

Monitoring

Watch any point, in the browser — an input exactly as it arrives, any switch, mux or edge inside a stream, or what an output’s consumers receive. One click on the flow canvas or an inputs/outputs row; the picture plays over MoQ (WebTransport) with no plug-in.
On demand, leased — a monitor runs only while someone is watching and is removed shortly after the last viewer leaves, so an idle relay pays nothing for it.
Sound and picture chooser — every track at that point, with its codec and language, and whether this browser can play it. Per-channel audio level meters, metered in the browser.
Opt-in AAC copy — a sound the browser cannot play (MP2, AC-3, Dolby E…) can be copied to AAC for the monitor only, at the operator’s request. It is the relay’s only transcode, it never touches the relayed stream, and it goes with the monitor.
Monitor wall — every stream as a live tile: state, bitrate in and out, consumers; problems bordered.

Recording

Anything can be recorded, opt-in, in either of two tiers:

What an input received, as it arrived.
What a stream served, after its switching and composition.
What an output transmitted — byte for byte the output’s own transport stream, with its PIDs, tables and timing, plus a copy of the tables at the start of each segment so every file opens cleanly.

Tier	What it is	In the browser
TS files	Chunked MPEG-TS, indexed by the engine as it writes each chunk; listed, served and downloadable	Play with seek across chunks of any length; the live edge is marked
Media store	An in-engine recorder whose content is time-addressable (TAMS)	Play, and cut: clips made in an embedded cut editor are written back into the store

Every recording is bounded on its own: a TS recording keeps a number of days or a number of GB, oldest chunks going first, and a media store does the same for everything in it; the dashboard shows what recordings hold now and, from each one’s own rate, what they will hold when full. A finished recording keeps a default retention, its own number of days, or forever. Deleting an input, stream or output asks whether its recordings go with it or stay until they expire. Neither tier decodes, and a recording is independent of the live path: starting or stopping it does not touch the stream.

Operations and integration


API	REST, with an OpenAPI description generated from the same schemas the relay validates against — the reference cannot drift from the runtime. Declarations are acknowledged only once they are durably written.
Event feed	Every state change pushed as it happens, as server-sent events: resumable after a disconnect, and filtered by stream, input, output or kind. No polling.
Operator UI	Live inbound and outbound views; a flow canvas that creates and edits a stream in place, with a monitor on every node and edge; a track picker previewing what each input carries; declare / edit forms with generated, copyable secrets.
Audit	A durable, human-readable trail of everything of substance — declarations, connections, rejections with their reason, switches and operator cuts, slates, secret rotations, kicks, restarts. Queryable over the API.
Assets	A library of uploaded MP4 files (slates today), with their tracks, codecs and resolution read from the file, and thumbnails.
Metrics	Prometheus endpoint: per-stream state, bitrate, source host, consumers attached.
Groups	Named sets of streams (an event, a customer) with shared defaults.
Timestamps	Pass-through of source timecode; live timestamp nudges on every ingest protocol — TS, SRT, RIST, RTMP and MoQ — for lip-sync and alignment.

Deployment and resilience


Packaging	OCI containers: the Norsk media engine and the relay control plane
Runtimes	Norsk-ctl product (register, configure, launch), Docker Compose
State	Declarations persist; after a restart the relay re-declares every stream, re-registers its secrets and keeps retrying anything that cannot restore yet — its route stays reserved
Recovery	Every ingest node is watched; if the engine loses one, the relay audits it and makes it again
Scale unit	One relay carries many streams. Measured: 300 streams, each pulled by two consumers, on a single 32-core x86 host — SRT with passphrases throughout, ~1.3 Mb/s per stream
Licensing	Norsk licence, per product

Standards and interoperability

SRT with the Haivision-authored streamid access-control convention, AES encryption and connection bonding.
RIST main and simple profiles, SRP.
SMPTE ST 2022-7 seamless protection on MPEG-TS ingest.
MPEG-TS, RTMP / RTMPS.
MoQ (IETF Media over QUIC) contribution ingest — interoperability demonstrated with other vendors at NAB 2026 — and MoQ over WebTransport for the browser monitor.
TAMS (Time-Addressable Media Store) for the recorder tier.

Roadmap highlights

Find streams by name. Encoders resolve a relay stream by its name through Norsk discovery, instead of being handed a host and port — so a replaced relay, as well as a replaced encoder, is invisible to the other side.
Zero-copy handover to Norsk encoders over norsk-link, with hitless dual-path delivery on the relay-to-encoder hop.
Timecode insertion where a source has none, so a primary/backup encoder pair produces boundary-aligned, interchangeable segments.
Relays serving each other across points of presence, and derived streams — processing done in a separate Norsk instance and related back to its source in the relay.

Get in touch

To arrange an evaluation — declare a stream, push to it from your encoder, pull it from two consumers, kill one, and watch the backup take over in the browser — contact info@id3as.com.