SRT Streaming with Raspberry Pi: Build a Portable SRT Relay

Why Raspberry Pi for SRT

A Raspberry Pi costs under $100, draws 5-15W, and fits in your pocket. For SRT streaming, that combination opens up use cases that a rack server never will: a relay node at a remote camera position, a portable encoder in the field, a bonding gateway in a backpack, or a monitoring probe at the edge of your network.

SRT itself is lightweight on the protocol side. The heavy part is encoding video, but if your workflow involves relaying or receiving an already-encoded stream, a Raspberry Pi handles it comfortably. Even encoding is viable at moderate resolutions thanks to the Pi’s hardware video encoder.

The Pi is not a replacement for a production server. It is a purpose-built edge node that sits where a full server cannot.

Hardware Requirements

Raspberry Pi Model Selection

Recommendation: Use a Pi 4 (4 GB) or Pi 5 for any serious work. The Pi 5 is roughly 2x faster per core and handles FFmpeg SRT operations with lower CPU load. Avoid the Pi Zero for anything beyond a single low-bitrate relay.

Networking

SRT runs over UDP. For reliable operation, use wired Ethernet, not Wi-Fi. The Pi 4 and Pi 5 both have true Gigabit Ethernet (not shared with USB like older models).

If your use case requires cellular connectivity (remote cameras, IRL streaming), add a USB 4G/5G modem or a HAT-based cellular module. Pair this with a USB Ethernet adapter for dual-path setups.

Storage and Power

• A 32 GB microSD card is sufficient for the OS and SRT tools. Use a Class A2 card for better random I/O.
• If recording streams locally, add a USB SSD. SD cards wear out under sustained write loads.
• Power the Pi with a quality 5V/3A supply (Pi 4) or 5V/5A supply (Pi 5). Underpowered Pis throttle the CPU under load, which kills real-time streaming performance.

Cooling

SRT relay workloads keep the CPU moderately busy. Encoding pushes it harder. Use a heatsink at minimum, and an active fan for sustained encoding. The Pi 5’s active cooler accessory is worth the $5.

Installing SRT and FFmpeg

Start with a clean Raspberry Pi OS (64-bit, Lite edition recommended for headless operation).

Update the System

sudo apt update && sudo apt upgrade -y

Install FFmpeg with SRT Support

The default FFmpeg package in Raspberry Pi OS includes SRT support:

sudo apt install -y ffmpeg

Verify SRT protocol support:

ffmpeg -protocols 2>/dev/null | grep srt

You should see srt listed under both input and output protocols.

Install the SRT Tools Directly

For lower-level control and diagnostics, install the SRT library and tools:

sudo apt install -y libsrt-openssl-dev srt-tools

This gives you srt-live-transmit, a lightweight tool for SRT relay without the overhead of FFmpeg’s demuxing and muxing pipeline.

Build FFmpeg from Source (Optional)

If you need the latest FFmpeg with hardware encoding support via Video4Linux2 (V4L2) and the newest SRT library:

sudo apt install -y build-essential nasm yasm cmake git \
  libsrt-openssl-dev libx264-dev libv4l-dev

git clone --depth 1 https://github.com/FFmpeg/FFmpeg.git
cd FFmpeg
./configure --enable-gpl --enable-libx264 --enable-libsrt \
  --enable-v4l2-m2m --enable-nonfree
make -j$(nproc)
sudo make install

This takes 20-30 minutes on a Pi 5 and around an hour on a Pi 4.

Setting Up an SRT Listener on the Pi

The simplest use case: the Pi listens for an incoming SRT stream and makes it available locally or forwards it somewhere else.

Using srt-live-transmit

srt-live-transmit is the most efficient way to relay SRT on a Pi because it does not decode or re-encode the stream. It passes packets through at the transport level.

Start a listener on port 9000 that outputs to a local UDP port:

srt-live-transmit "srt://:9000?mode=listener&latency=500" \
  "udp://127.0.0.1:5000" -v

Or relay to another SRT destination:

srt-live-transmit "srt://:9000?mode=listener&latency=500" \
  "srt://destination-server:9000?mode=caller&latency=500" -v

Using FFmpeg as a Listener

FFmpeg is necessary when you need to inspect, transcode, or record the stream:

ffmpeg -i "srt://:9000?mode=listener&latency=500" \
  -c copy -f mpegts "srt://destination:9000?mode=caller&latency=500"

The -c copy flag means no transcoding. FFmpeg demuxes the incoming MPEG-TS, and remuxes it to the output. CPU usage stays under 5% for a typical 6 Mbps stream.

Firewall Rules

Open the SRT port on the Pi:

sudo ufw allow 9000/udp

If you are behind a NAT (e.g., the Pi is on a home network), forward UDP port 9000 on your router to the Pi’s local IP.

SRT Relay Configuration

A relay sits between a source and a destination, providing a point of control and monitoring. This is where the Pi shines as a cheap, deployable edge node.

Basic Relay (Listener to Caller)

Accept a stream from a remote encoder, forward it to a central server:

srt-live-transmit \
  "srt://:9000?mode=listener&latency=500&passphrase=MySecureKey123" \
  "srt://central-server.example.com:9000?mode=caller&latency=500&passphrase=ServerKey456"

Multi-Output Relay with FFmpeg

Receive one stream, output to two destinations:

ffmpeg -i "srt://:9000?mode=listener&latency=500" \
  -c copy -f mpegts "srt://server-a:9000?mode=caller&latency=500" \
  -c copy -f mpegts "srt://server-b:9001?mode=caller&latency=500"

Relay with Local Recording

Forward the stream while saving a local copy:

ffmpeg -i "srt://:9000?mode=listener&latency=500" \
  -c copy -f mpegts "srt://central-server:9000?mode=caller&latency=500" \
  -c copy -f mpegts "/mnt/usb-ssd/recordings/$(date +%Y%m%d_%H%M%S).ts"

Run as a Systemd Service

For unattended operation, create a systemd unit:

sudo tee /etc/systemd/system/srt-relay.service << 'EOF'
[Unit]
Description=SRT Relay
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/bin/srt-live-transmit \
  "srt://:9000?mode=listener&latency=500" \
  "srt://central-server:9000?mode=caller&latency=500"
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now srt-relay

The service restarts automatically on failure, which is critical for unattended remote deployments.

Connecting to Vajra Cast

A Raspberry Pi relay pairs naturally with Vajra Cast as the central gateway. The Pi handles edge collection at the remote site, and Vajra Cast handles routing, monitoring, transcoding, and distribution.

Pi as a Field Relay to Vajra Cast

Configure the Pi to push its received stream to a Vajra Cast SRT listener:

srt-live-transmit \
  "srt://:9000?mode=listener&latency=300" \
  "srt://vajracast.example.com:9100?mode=caller&latency=500&passphrase=ProductionKey"

On the Vajra Cast side, create an SRT Listener ingest on port 9100 with matching passphrase and latency settings. The stream appears in the Vajra Cast dashboard with full real-time metrics: bitrate, RTT, packet loss, jitter. From there you can route to any number of outputs, apply latency tuning, or transcode as needed.

Pi as a Pull Point for Vajra Cast

Alternatively, run the Pi as an SRT listener and configure Vajra Cast as a caller that pulls the stream. This is useful when the Pi has a public IP (or port-forwarded address) and you want the central server to control when it connects.

In Vajra Cast, create an SRT Caller ingest pointed at the Pi’s address and port. Vajra Cast initiates the connection and begins pulling the stream.

Performance Tuning

Bitrate Limits

The Pi 4 and Pi 5 handle SRT relay comfortably up to about 50 Mbps per stream. Beyond that, CPU usage for MPEG-TS processing in FFmpeg becomes significant. For srt-live-transmit (no demux/mux), throughput is higher because the tool operates at the packet level.

Practical limits for relay (no transcoding):

CPU Tuning

Set the CPU governor to performance mode to prevent frequency scaling during streaming:

echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

Make it persistent across reboots:

sudo apt install -y cpufrequtils
echo 'GOVERNOR="performance"' | sudo tee /etc/default/cpufrequtils
sudo systemctl restart cpufrequtils

Network Buffer Tuning

Increase the UDP receive buffer for high-bitrate streams:

sudo sysctl -w net.core.rmem_max=26214400
sudo sysctl -w net.core.rmem_default=26214400

Make it persistent:

echo "net.core.rmem_max=26214400" | sudo tee -a /etc/sysctl.conf
echo "net.core.rmem_default=26214400" | sudo tee -a /etc/sysctl.conf

SRT Latency Settings

On a Pi acting as relay, the latency parameter needs to account for both the inbound and outbound network conditions. A good starting point:

• LAN relay: 120ms
• Internet relay, same region: 500ms
• Cross-continent relay: 1000-2000ms
• Cellular uplink: 1500-3000ms

For detailed guidance on SRT latency parameters, see SRT Latency Tuning.

Real-World Use Cases

Remote Camera Relay

Place a Pi at a remote camera position (a rooftop, a stadium press box, a church balcony). The camera feeds HDMI or SDI into a cheap hardware encoder like the Magewell Ultra Encode, which outputs SRT to the Pi on the local network. The Pi relays the stream over the internet to your central Vajra Cast instance.

Why not skip the Pi and send directly from the encoder? Because the Pi gives you a local monitoring point, local recording as backup, and the ability to relay to multiple destinations without reconfiguring the encoder. If the internet link drops, the Pi keeps recording locally.

IRL Streaming with Cellular Bonding

Pair a Pi with multiple USB cellular modems and use SRTLA bonding to aggregate bandwidth. The Pi runs srtla_rec or acts as the SRTLA sender, bonding 2-3 cellular connections into a single reliable uplink. The bonded stream feeds into Vajra Cast, which distributes to Twitch, YouTube, or any other destination.

This is essentially a DIY BELABOX. You trade the polished BELABOX interface for flexibility and lower cost. For experimenters and budget-constrained productions, it is a valid path.

Protocol Bridge

The Pi can bridge between protocols. Receive an RTMP stream from a legacy encoder and relay it as SRT:

ffmpeg -listen 1 -i rtmp://0.0.0.0:1935/live/stream \
  -c copy -f mpegts "srt://vajracast-server:9000?mode=caller&latency=500"

Or receive SRT and output as RTMP for a platform that does not support SRT ingest:

ffmpeg -i "srt://:9000?mode=listener&latency=500" \
  -c copy -f flv rtmp://live.twitch.tv/app/your-stream-key

Network Monitoring Probe

Deploy a Pi as an SRT monitoring endpoint. Have it connect to your SRT streaming gateway as a caller, receive the stream, and log SRT statistics (RTT, loss, jitter) without displaying the video. This is useful for validating network quality to a remote site before an event.

ffmpeg -i "srt://server:9000?mode=caller&latency=500" \
  -f null - 2>&1 | grep -E "speed|bitrate"

Limitations

Be realistic about what a Raspberry Pi cannot do well.

Hardware encoding quality is limited. The Pi’s V4L2 H.264 encoder (on the Pi 4) produces acceptable quality at 1080p30 but falls well short of x264 medium or Intel QSV. The Pi 5 drops the Broadcom hardware encoder entirely and relies on software encoding, which is CPU-constrained. If encoding quality matters, use the Pi as a relay and encode on proper hardware.

No HEVC hardware encoding. Neither the Pi 4 nor Pi 5 has hardware HEVC encoding. Software HEVC encoding on a Pi is too slow for real-time use. If your workflow requires HEVC, encode elsewhere and use the Pi for relay only.

Thermal throttling under sustained load. Without active cooling, the Pi 4 throttles after 10-15 minutes of heavy CPU usage. A passive heatsink helps, but active cooling is necessary for 24/7 encoding workloads.

SD card reliability. SD cards are not designed for continuous writes. If you are recording streams, use a USB SSD. For relay-only operation (no local writes), the SD card is fine.

No redundant power or networking. The Pi has one Ethernet port and no built-in UPS. For production deployments, add a PoE HAT (power and network over one cable) and a small UPS battery. Accept that a Pi relay is a cost-optimized edge node, not a fault-tolerant appliance.

For critical production workflows, the Pi serves best as one layer in a larger architecture: cheap, replaceable edge nodes feeding into a robust gateway like Vajra Cast that handles failover, multi-destination routing, and SRT protocol management at the core.

Getting Started

The fastest path to a working SRT relay on a Pi:

1. Flash Raspberry Pi OS Lite (64-bit) to your SD card
2. Run sudo apt update && sudo apt install -y ffmpeg srt-tools
3. Start a relay: srt-live-transmit "srt://:9000?mode=listener&latency=500" "srt://your-server:9000?mode=caller&latency=500"
4. Point your encoder at the Pi’s IP on port 9000
5. Verify the stream arrives at your destination

Total setup time: under 15 minutes. Total cost: under $100. For a deeper walkthrough of SRT configuration, see the SRT Streaming Setup Guide.