What Is Live Stream Routing?

Live stream routing is the process of directing video signals from their sources to their destinations. At its simplest, routing takes a video input and sends it to an output. In practice, professional routing involves protocol conversion, signal splitting, quality monitoring, audio channel management, failover logic, and real-time control, all happening simultaneously across dozens or hundreds of streams.

If you have worked with physical video routers in a broadcast facility (devices with SDI inputs on one side and SDI outputs on the other), live stream routing is the IP equivalent. But instead of patching cables on a physical matrix, you are configuring software-defined routes that can convert between protocols, duplicate signals without hardware, and be managed remotely via API.

Stream routing is the foundational layer of any video infrastructure. Every other capability (failover, transcoding, distribution, monitoring) is built on top of the routing engine. Get routing right, and everything else follows.

The Anatomy of a Route

In Vajra Cast, every route has three components:

Input (Source)

Where the video comes from. An input can be:

  • SRT Listener: opens a port and waits for an incoming SRT connection
  • SRT Caller: initiates an outbound SRT connection to a remote source
  • SRTLA: bonded SRT input for cellular/multi-path transport (BELABOX compatible)
  • RTMP: receives RTMP push from encoders (OBS, vMix, hardware encoders)
  • HTTP/TS: pulls an MPEG-TS stream from a URL
  • UDP: receives a unicast UDP stream from a local network source

Each input is independently configured with its own protocol parameters: encryption settings for SRT, latency buffer, stream key for RTMP, and so on.

Processing (Optional)

What happens to the signal between input and output. Processing includes:

  • Transcoding: change codec (H.264 to H.265), resolution (1080p to 720p), or bitrate. Vajra Cast supports Intel QSV and VAAPI hardware acceleration for real-time transcoding without CPU overhead.
  • Audio routing: remap audio channels, downmix 5.1 to stereo, extract specific channels, apply gain control. The audio matrix gives you per-channel control.
  • VMAF quality analysis: automated perceptual quality scoring on any active route. One-click analysis with historical trend tracking.

Processing is optional. Many routes are passthrough. The signal is forwarded without modification, which requires near-zero CPU. Vajra Cast handles passthrough routing with under 50ms of added latency.

Output (Destination)

Where the video goes. An output can be:

  • SRT (Listener or Caller): push to downstream SRT servers, with AES encryption
  • SRTLA: bonded SRT output to remote receivers
  • RTMP: push to YouTube Live, Twitch, Facebook Live, or any RTMP endpoint
  • HTTP/TS: built-in HTTP server for direct playback in VLC, ffplay, or web players
  • UDP: unicast to network destinations
  • HLS: adaptive bitrate streaming with configurable segment length and a built-in live viewer counter

A single route can have multiple outputs. This is where zero-copy distribution becomes critical.

Zero-Copy Distribution: One Input, Unlimited Outputs

The most common routing requirement is one-to-many: take a single input and send it to multiple destinations simultaneously. A sports feed goes to YouTube, Twitch, Facebook, a CDN, and a local recording, all at once.

The naive approach is to decode the input once per output, then re-encode and send. This scales linearly with CPU: 5 outputs means 5x the processing. At 10 outputs, most servers are overwhelmed.

Vajra Cast solves this with zero-copy distribution. Internally, the input stream data is read once into memory, and each output reads from that same memory buffer. There is no per-output decoding or copying. Adding a second output costs the same CPU as the first: effectively zero for passthrough routes.

                    ┌→ SRT Push (CDN 1)
                    ├→ SRT Push (CDN 2)
SRT Input → Buffer  ├→ RTMP Push (YouTube)
                    ├→ RTMP Push (Twitch)
                    ├→ HLS (web player)
                    └→ HTTP/TS (VLC monitoring)

This architecture means you can route one input to 50 destinations on a modest server. The bottleneck becomes network bandwidth, not CPU.

Key benefits:

  • No CPU overhead per additional output
  • Each output can use a different protocol (SRT, RTMP, HLS, UDP)
  • Outputs can be added, removed, or reconfigured while the stream is live (hot management)
  • Each output has independent health monitoring

For more on how Vajra Cast achieves failover when combining multiple inputs, see Video Stream Failover: Complete Guide.

Protocol Conversion

Real-world video infrastructure rarely uses a single protocol end-to-end. Encoders send SRT. Social platforms accept RTMP. Web players need HLS. Monitoring stations pull HTTP/TS. A stream router must convert between all of these transparently.

Vajra Cast performs protocol conversion at the routing layer. Any input protocol can be routed to any output protocol:

Input ProtocolOutput ProtocolUse Case
SRTRTMPRemote SRT encoder to YouTube/Twitch
RTMPSRTLegacy encoder to SRT-based infrastructure
SRTHLSCamera feed to web player
SRTLASRTCellular bonded input to production SRT network
UDPRTMPLocal multicast source to social platform
HTTP/TSSRTCDN pull to SRT redistribution

Protocol conversion in passthrough mode (no transcoding) adds minimal latency, typically under 50ms. The signal is remuxed (repackaged) into the target protocol’s container format without touching the video or audio codec.

When transcoding is required (e.g., converting H.265 input to H.264 output for RTMP compatibility), Vajra Cast uses Intel QSV or VAAPI hardware acceleration. This keeps CPU usage low even when performing codec conversion. If you are planning a protocol transition for your infrastructure, our RTMP to SRT migration guide covers the process step by step.

For a detailed comparison of SRT and RTMP protocol characteristics, see SRT vs RTMP: Which Protocol Should You Use?.

The Diagram View: Visual Route Management

Managing routes in a list or table works fine for a handful of streams. But when you have 20, 30, or 50+ routes, you need a visual representation of your signal flow.

Vajra Cast includes an interactive diagram view built with React Flow. Every route is displayed as a visual graph:

  • Input nodes on the left, one per source, colored by protocol
  • Processing nodes in the center: transcoding, audio routing, failover logic
  • Output nodes on the right, one per destination, colored by protocol
  • Connection lines between nodes, with real-time status indicators

The diagram is not a static picture. It is a live, interactive tool:

  • Drag and drop to rearrange the layout
  • Click any node to see detailed configuration and live metrics (bitrate, packet loss, connection state)
  • Real-time overlay shows data flowing through each connection: green for healthy, yellow for degraded, red for failed
  • Scale comfortably to 50+ routes without performance degradation

For operators managing complex infrastructure, the diagram view provides immediate situational awareness. Instead of scrolling through a table looking for the one failed route, you see the red node instantly in the visual graph.

Audio Matrix Routing

Video routing gets most of the attention, but audio routing is equally critical and often more complex. A video signal might carry 2, 6, or 8 audio channels, and the output requirements rarely match the input.

Common audio routing scenarios:

  • Downmix 5.1 to stereo for social platform outputs that only accept 2-channel audio
  • Extract a specific channel pair (e.g., commentary on channels 3-4) for a particular output
  • Mix multiple audio sources into a single output (e.g., venue audio + commentary + music bed)
  • Apply per-channel gain to balance levels between sources
  • Route 7.1 surround to a broadcast feed while sending a stereo downmix to web outputs

Vajra Cast’s audio matrix gives you per-channel control over every route:

Input Channels:     Output Channels:
┌─────────────┐     ┌──────────────┐
│ Ch 1 (Left) │────→│ Ch 1 (Left)  │  Stereo output
│ Ch 2 (Right)│────→│ Ch 2 (Right) │
│ Ch 3 (Comm) │     └──────────────┘
│ Ch 4 (Comm) │
│ Ch 5 (LFE)  │     ┌──────────────┐
│ Ch 6 (Surr) │     │ Ch 1 (Comm)  │  Commentary only
│ Ch 7 (Surr) │     │ Ch 2 (Comm)  │
│ Ch 8 (Music)│     └──────────────┘
└─────────────┘

Each output on a route can have its own audio channel mapping. The same video signal can feed one output with full 5.1 audio and another with a stereo commentary-only mix. For practical examples of audio channel mapping in live broadcast workflows, see our audio routing for live broadcast guide.

REST API: Programmatic Route Management

Manual route management works for small deployments. But when your infrastructure handles dozens of routes, integrates with scheduling systems, or needs to respond to external events, you need automation.

Vajra Cast provides a full REST API with complete CRUD (Create, Read, Update, Delete) operations on every object:

Creating a Route via API

curl -X POST https://your-vajracast:8080/api/routes \
  -H "Authorization: Bearer YOUR_JWT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "sports-main",
    "input": {
      "type": "srt-listener",
      "port": 9000,
      "latency": 500,
      "encryption": "aes-256",
      "passphrase": "YourSecurePassphrase"
    },
    "outputs": [
      {
        "type": "rtmp",
        "url": "rtmp://a.rtmp.youtube.com/live2",
        "key": "your-stream-key"
      },
      {
        "type": "srt-caller",
        "host": "backup-server.example.com",
        "port": 9001,
        "latency": 200
      }
    ]
  }'

Listing All Routes

curl -X GET https://your-vajracast:8080/api/routes \
  -H "Authorization: Bearer YOUR_JWT_TOKEN"

Modifying an Output (Hot Management)

curl -X PATCH https://your-vajracast:8080/api/routes/sports-main/outputs/1 \
  -H "Authorization: Bearer YOUR_JWT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "enabled": false
  }'

This disables the output without affecting other outputs on the same route. The stream continues to all other destinations.

API Authentication

The API uses JWT (JSON Web Token) authentication. Tokens are generated through the web interface or via a login endpoint. All API calls are logged in the audit trail for compliance and troubleshooting.

API Use Cases

  • Scheduling integration: automatically create and destroy routes based on an event schedule
  • Monitoring integration: pull real-time metrics from the API and feed them into your existing monitoring stack
  • Disaster recovery: script the recreation of all routes on a standby server
  • Multi-tenant platforms: provision routes programmatically for customers
  • CI/CD for infrastructure: version-control your route configurations and apply them automatically on deployment

The API is fully documented with OpenAPI (Swagger) specifications, so you can generate client libraries in any language.

Routing Architectures: Patterns for Production

Pattern 1: Simple Ingest and Distribution

The most common pattern. One encoder sends to Vajra Cast, which distributes to multiple platforms:

OBS/vMix → RTMP → Vajra Cast → RTMP → YouTube
                              → RTMP → Twitch
                              → RTMP → Facebook
                              → HLS  → Website player
                              → SRT  → Recording server

This replaces the need for multiple encoder outputs or a separate restreaming service. Vajra Cast handles the fan-out with zero-copy efficiency. For a complete walkthrough of this pattern, see our multi-destination streaming guide.

Pattern 2: Multi-Source Production Hub

Multiple sources feed into Vajra Cast, which routes each one to its appropriate destination:

Camera 1 (SRT)  → Vajra Cast → SRT → Production Switcher
Camera 2 (SRT)  → Vajra Cast → SRT → Production Switcher
Commentary (SRT)→ Vajra Cast → SRT → Production Switcher
Graphics (RTMP) → Vajra Cast → SRT → Production Switcher

Each source has its own route with independent failover, monitoring, and protocol conversion. The production switcher receives all feeds via SRT, regardless of the original source protocol.

Pattern 3: Contribution and Distribution Network

A layered architecture where Vajra Cast instances serve different roles:

Venue A → SRT → Vajra Cast (Edge) → SRT → Vajra Cast (Core) → CDN
Venue B → SRT → Vajra Cast (Edge) → SRT ↗                    → Archive
Venue C → SRT → Vajra Cast (Edge) → SRT ↗                    → Social

Edge instances handle ingest, local failover, and protocol normalization. The core instance aggregates all feeds and handles distribution. This architecture scales horizontally. Add edge instances as you add venues.

Pattern 4: Monitoring and QC

Route a tap (copy) of every production stream to a monitoring output:

Production route: SRT Input → SRT Output (CDN)
                            → HTTP/TS Output (QC monitoring in VLC)
                            → VMAF analysis (quality scoring)

The monitoring outputs use the same zero-copy mechanism, so adding QC taps costs zero CPU. Operators can watch any stream in VLC by pulling the HTTP/TS URL, and VMAF scores provide objective quality measurement without subjective human evaluation.

Hot Management: Change Routes Without Interruption

In a live production environment, the configuration is never static. Outputs need to be added, removed, enabled, or disabled in response to real-time operational needs. Vajra Cast supports hot management: all route modifications happen without interrupting running streams.

Operations you can perform while live:

  • Add an output to an existing route (e.g., start streaming to a new platform mid-event)
  • Remove an output (e.g., stop the Facebook feed but keep YouTube running)
  • Enable/disable an output temporarily (e.g., pause the recording without deleting the configuration)
  • Modify output parameters (e.g., change the RTMP stream key for a new YouTube broadcast)
  • Add a new input to the failover chain (e.g., connect a backup encoder that just came online)
  • Reorder failover priorities (e.g., promote the backup to primary)

None of these operations require a restart. None affect other routes or outputs on the same route. The change takes effect immediately.

This is a fundamental difference from systems that require a configuration reload or process restart to apply changes. In live production, a restart means downtime, and downtime means failure.

Monitoring Your Routes

Every route in Vajra Cast exposes real-time metrics:

Per-Input Metrics

  • Connection state (connected/disconnected/connecting)
  • Bitrate (current, average, peak)
  • Packet loss rate (for SRT/UDP)
  • RTT and jitter (for SRT)
  • Continuity counter errors (MPEG-TS)

Per-Output Metrics

  • Connection state
  • Bitrate (sent)
  • Retransmission rate (for SRT)
  • Queue depth (output buffer utilization)
  • Dropped frames (if output cannot keep up)

Route-Level Metrics

  • Active input (which source is currently feeding the output)
  • Failover event count
  • Uptime (time since last route restart)
  • VMAF quality score (if analysis is enabled)

All metrics are available through the web dashboard, the REST API, and the Prometheus /metrics endpoint. For Grafana integration details and pre-built dashboards, see Broadcast Streaming Software: Professional Video Infrastructure.

Planning Your Routing Infrastructure

Hardware Sizing

Vajra Cast is lightweight. Route capacity depends on whether you are doing passthrough or transcoding:

WorkloadCPURAMNetwork
1-10 passthrough routes2 cores4 GB1 Gbps
10-30 passthrough routes4 cores8 GB1 Gbps
30-50+ passthrough routes8 cores16 GB10 Gbps
With hardware transcodingIntel QSV GPU16 GB1 Gbps
Enterprise (50+ routes, mixed)8+ cores + QSV32 GB10 Gbps

Passthrough routing uses minimal CPU because the stream data is never decoded. It is remuxed and forwarded. Transcoding is the operation that demands compute, and hardware acceleration (Intel QSV or VAAPI) offloads that work from the CPU to the GPU.

Network Considerations

  • Bandwidth: Plan for 1.5x your aggregate bitrate to account for SRT retransmissions and protocol overhead
  • Ports: Each SRT listener needs its own UDP port. Plan your port ranges accordingly (e.g., 9000-9099 for 100 SRT inputs)
  • Firewall: SRT uses UDP. Ensure your firewall allows inbound UDP on your listener ports
  • DNS: Use DNS names for SRT caller destinations to enable failover at the DNS level

Deployment with Docker and Kubernetes

Vajra Cast runs as a lightweight Docker container, making it straightforward to deploy on any infrastructure:

docker run -d \
  --name vajracast \
  -p 8080:8080 \
  -p 9000-9099:9000-9099/udp \
  -v /data/vajracast:/data \
  vajracast/vajracast:latest

For multi-instance deployments, Kubernetes orchestration with PostgreSQL as the shared state store allows horizontal scaling. Terraform modules are available for infrastructure-as-code provisioning.

Next Steps

Frequently Asked Questions

What is live stream routing?

Live stream routing is the process of directing video signals from sources to destinations, including protocol conversion, signal splitting, and quality management.

Can I route one input to multiple outputs?

Yes. Vajra Cast uses zero-copy distribution to send one input to unlimited outputs without CPU overhead. Each output can use a different protocol.

Is there an API for automated routing?

Vajra Cast provides a full REST API for programmatic route management. Create, modify, and delete routes via HTTP calls, perfect for automation and integration.

What protocols does Vajra Cast support for routing?

SRT (caller/listener/rendezvous), SRTLA, RTMP, HTTP/TS, UDP unicast/multicast, and HLS. Any input protocol can be routed to any output protocol.