In this article, the term gateway refers specifically to a restreamer—a device that receives a media stream and forwards it further without deep analysis or transformation of the elementary streams. At first glance, restreamers may appear to serve a simple function. In reality, the task is more complex than it seems — especially considering the high bitrates, multiple simultaneous streams, and critical aspects like transmission efficiency, latency, and broadcast stability.
A Simple Device with a Complex Task
Restreamers do not demultiplex transport streams or interact with the elementary streams they contain. Their work is limited to the transport layer: for example, they can inspect the structure of TS packets and monitor continuity counters, which helps detect packet loss (CC errors). However, issues at the elementary stream level — such as video freezing or audio dropouts — go undetected, as diagnosing such problems falls outside the scope of their functionality.
Despite this, restreamers are crucial in scenarios requiring reliable and scalable content delivery.
Live Streaming: From Studio to Viewer
One of the most common use cases is organizing a live broadcast — for instance, a sports event or a studio-based show. This setup typically involves two gateways:
The first gateway, located at the source, captures the SDI signal from cameras (either directly or after additional processing like logo insertion or graphics overlay), encodes it, multiplexes it into a transport stream, and sends it via SRT protocol to the cloud.
The second gateway, deployed in the cloud infrastructure, performs SRT-to-SRT restreaming: it receives the stream and redistributes it to client stations.
This architecture addresses two key challenges:
- It moves the client access point outside the local network (which often has limited external access).
- It reduces the local channel load: if the encoded stream has a bitrate of 10 Mbps, each client adds the same load (10 clients = 100 Mbps). By placing the distribution point in the cloud, bandwidth consumption shifts from local infrastructure to cloud resources.
Local IPTV Distribution
Another scenario is local IPTV broadcasting — for example, in hotels. Encoded content is delivered via SRT to a gateway, converted to UDP, and distributed across the local network via multicast. The multicast stream can then be received by STBs or TVs. Unlike in the live streaming scenario, we do not move the connection point outside the local network here; instead, we deliver the content into the local network.
Source Redundancy
Gateways are also used within local networks to organize source redundancy. These sources may use different protocols (UDP, RTP, SRT, RIST) and come through different network interfaces. For example, a system can receive a primary and several backup sources from different subnets or even external networks, with priority settings for failover.
The gateway automatically switches to a backup source when a trigger event occurs — such as loss of the main signal. While it does not analyze the content like a transcoder, it can detect packet loss, bitrate anomalies, and other transport-level issues. Additionally, it can monitor backup sources in advance and switch only when they are confirmed to be available, minimizing the risk of errors or false triggers. The switching time — typically between 100 and 200 ms — is acceptable for most broadcast scenarios.
ST 2022-7: Transmission Path Redundancy
Another important use case is transmission redundancy based on the SMPTE ST 2022-7 standard. This configuration involves two specialized gateways:
- A Splitting Gateway on the sending side splits the original stream into several identical copies.
- A Switching Gateway on the receiving side analyzes RTP packet numbers and reconstructs the original stream.
Example: A studio sends a signal to a headend station via the public internet using three independent providers — ISP1, ISP2, and ISP3. Even if one connection fails, the system continues delivering the stream without interruption by filling in missing packets from the other links. This significantly improves broadcast resilience, particularly in unstable network environments.
Elecard CodecWorks Gateway: The Core of Reliable Restreaming
A gateway is more than just a “stream forwarder.” It has become a key component of modern broadcasting systems, enabling efficient stream management, content distribution, redundancy, and protocol adaptation.
The scenarios described in this article are effectively implemented using Elecard CodecWorks Gateway, a fully software-based solution compatible with all x86 hardware platforms.
Hardware Independence and Scalability
Elecard CodecWorks Gateway is compatible with a wide range of hardware platforms — from compact solutions to high-performance servers capable of handling total stream bitrates up to 6500 Mbps. This flexibility allows the system to be used in various scenarios, from local hotel networks to nationwide broadcasting infrastructures.
A great example of a compact solution is the Elecard CodecWorks Box. This portable device can capture two 12G-SDI signals, encode two 4K HEVC streams with bit rates around 40 Mbps each, multiplex them, and transmit via the SRT protocol. When used for restreaming, the device provides bandwidth load up to 300 Mbps.
Elecard CodecWorks Box
Broadcast Stability Control
In certain use cases — such as working with DVB modulators — it is essential to monitor and control stream parameters. These devices are highly sensitive to stream stability, especially to the Inter Arrival Time (IAT) — the time interval between arriving packets.
Even if a stream formally complies with the TR 101290 standard, high or unstable IAT values can cause failures. IAT is also used as a measure of network jitter. To evaluate stream stability, key indicators such as average and peak IAT are used.
Elecard CodecWorks Gateway includes rate control features that manage data transmission speed. The core method is output stream buffering, which smooths bitrate fluctuations but introduces additional latency. For instance, a 4–5 second buffer ensures stable delivery but also delays the output by the same duration.
The system supports three rate control modes.
- No Rate Control Mode
- The stream is passed directly from input to output without buffering.
- Offers minimal latency and low CPU load.
- Suitable for simple restreaming when the input stream is already stable.
- Not recommended for unstable input streams, remultiplexing, or transcoding, as any issues in the original stream will be passed through to the output.
- Average Mode (Average Bitrate Control)
- The stream is buffered until a certain fill level is reached.
- Precise sending time is calculated for each packet based on the actual input bitrate, measured by system clocks.
- This mode is independent of PCR timestamps, making it effective when PCR is missing or inaccurate.
- Higher CPU usage compared to the first mode.
- Not suitable for streams with bitrate fluctuations exceeding 2 seconds, such as streams converted from HLS to UDP.
- TS PCR Mode
- The stream is buffered, packet sending time is based on PCR timestamps.
- Standard mode for broadcasting TS streams.
- Ensures the output bitrate matches the PCR-defined bitrate in the stream.
Both Average and TS PCR modes support the high-precision-broadcasting option, which enables extremely accurate IAT calculations. This is useful at high bitrates (10 Mbps and above) or when sub-millisecond IAT precision is required. However, enabling this feature significantly increases CPU load.
Stream Filtering Support
For multicast scenarios, Elecard CodecWorks Gateway supports SSM (Source-Specific Multicast) — a mechanism that allows receivers to select a specific data source. As a result, traffic is only received from the designated source, which reduces network load and increases streaming security.
To use SSM, the network equipment must support IGMPv3. Compared to ASM (Any-Source Multicast), SSM provides more reliable and efficient filtering without requiring complex routing configurations.
Try Elecard CodecWorks Gateway
Author
Dmitriy Shmakov
Leading engineer at Elecard. He has been working in video analysis since 2021. Dmitriy is in charge of support of the Elecard's largest clients, such as Telstra, Globo, Amagi, Innet, etc.
September 9, 2025