Multi-Protocol Streaming: RTSP, HTTP, HLS, SRT & RTMP Explained

Why Multi-Protocol Support Matters

In the real world, video sources come in every protocol imaginable. IP cameras speak RTSP. Web-based sources use HTTP or HTTPS. Content delivery networks serve HLS playlists. Professional contribution feeds use SRT for its error correction. And encoders like OBS, Wirecast, and vMix push via RTMP. A streaming server that only supports one or two protocols forces you to convert sources externally, adding complexity, cost, and points of failure to your workflow.

Multi-protocol support means your streaming server can accept input from any source regardless of its native protocol, process that input (transcoding, passthrough, or restreaming), and deliver it to viewers as standard HLS output that plays on every device. This eliminates the need for protocol converters, simplifies your architecture, and lets you focus on content rather than infrastructure.

RTSP: The IP Camera Standard

RTSP (Real-Time Streaming Protocol) is the dominant protocol for IP cameras, DVRs, NVRs, and surveillance systems. Virtually every network camera manufactured in the last decade supports RTSP output, making it the most common source protocol for security and monitoring applications.

RTSP operates as a control protocol — it establishes and manages the media session while the actual video data is typically delivered over RTP (Real-time Transport Protocol). The default port is 554, though many cameras allow custom port configuration.

Typical RTSP URL formats:

• rtsp://camera-ip:554/stream1 — basic camera stream
• rtsp://username:password@camera-ip:554/cam/realmonitor?channel=1&subtype=0 — authenticated stream with channel selection (common for Dahua cameras)
• rtsp://username:password@camera-ip:554/Streaming/Channels/101 — Hikvision format

RTSP is ideal for pulling streams from devices on your local network or accessible via VPN. It is less suited for delivery over the public internet due to firewall traversal issues and lack of adaptive bitrate support.

HTTP/HTTPS: Web Stream Sources

HTTP and HTTPS are the standard protocols for web-based video sources. This includes direct links to video files, CDN-hosted streams, and any source accessible via a standard web URL. HTTPS adds TLS encryption for secure transport.

HTTP sources are common when pulling content from web services, cloud storage, or third-party content providers that expose their streams via web URLs. The protocol handles large files efficiently and works reliably through firewalls and proxies.

Typical HTTP URL formats:

• http://source-server.com/live/stream.ts — direct MPEG-TS stream
• https://cdn.example.com/channel1/index.m3u8 — HLS playlist over HTTPS
• http://radio-server.com:8000/stream — Shoutcast/Icecast audio stream

HLS: Playlist-Based Input

HLS (HTTP Live Streaming) is Apple's adaptive bitrate streaming protocol that has become the de facto standard for video delivery on the web. As an input protocol, HLS allows your server to consume existing HLS streams — pulling the .m3u8 playlist and downloading segments for re-processing or redistribution.

HLS works by dividing the stream into small segments (typically 2-10 seconds each) listed in a playlist file. The player downloads segments sequentially, allowing adaptive quality switching between segments. When used as an input source, your streaming server reads the playlist, downloads each segment, and processes the content just like any other input.

This is particularly useful for:

• Rebroadcasting existing HLS streams from other servers or CDNs
• Pulling content from platforms that only offer HLS output
• Transcoding HLS sources to different quality levels
• Aggregating multiple HLS sources into a unified platform

SRT: Modern Low-Latency Contribution

SRT (Secure Reliable Transport) is a modern open-source protocol designed specifically for live video transport over unpredictable networks. Developed by Haivision, SRT has quickly become the preferred protocol for professional contribution feeds where reliability and low latency are critical.

SRT's key advantages:

• Low Latency: Approximately 120ms end-to-end latency, significantly lower than HLS (10-30 seconds) and competitive with RTMP
• Error Correction: Built-in ARQ (Automatic Repeat reQuest) retransmits lost packets, maintaining stream quality even over lossy networks
• AES Encryption: Native 128/256-bit AES encryption protects content in transit without requiring a separate TLS layer
• Firewall Traversal: SRT uses UDP and supports both caller and listener modes, making it easier to traverse firewalls than RTSP

SRT URL format: srt://server-ip:port?streamid=your-stream-key

SRT is ideal for remote contribution — sending live video from a venue, remote studio, or field location to your streaming server over the public internet. Its error correction makes it reliable even on connections with packet loss. For a deeper dive, see our SRT protocol guide.

RTMP: Legacy but Essential

RTMP (Real-Time Messaging Protocol) was originally developed by Macromedia (later Adobe) for Flash-based streaming. While Flash is long gone, RTMP remains the most widely supported ingest protocol across streaming software. OBS Studio, Wirecast, vMix, and virtually every hardware encoder support RTMP output.

RTMP operates on port 1935 by default and uses a persistent TCP connection for reliable delivery. It provides low-latency ingest (typically 1-3 seconds) and supports both video and audio in a single connection.

RTMP URL format for ingest: rtmp://server-ip:1935/live/stream-key

While RTMP is not recommended for delivery to viewers (it requires Flash or specialized players), it remains the standard protocol for getting content into your streaming server from encoders. For a detailed comparison with HLS for delivery, see our HLS vs RTMP guide.

All Protocols Convert to HLS Output

Regardless of which input protocol your source uses, StreamDev converts all streams to HLS for output delivery. HLS is the universal playback standard — it works in every modern web browser, on iOS and Android devices, smart TVs, set-top boxes, and media players. This means you never need to worry about viewer compatibility regardless of your source protocol.

The conversion process is transparent: your server receives the input stream via its native protocol, processes it (passthrough or transcoding), and outputs HLS segments and playlists that any player can consume.

Advanced Input Options

Some sources require additional configuration beyond a simple URL. StreamDev supports several advanced input options to handle these cases:

Custom User-Agent

Some HTTP sources check the User-Agent header and return 403 Forbidden errors if the request does not come from an expected client. Setting a custom User-Agent (such as a browser User-Agent string) resolves these access issues without changing anything on the source server.

Referer Header

Sources protected by CORS (Cross-Origin Resource Sharing) policies may require a specific Referer header. This is common with CDN-hosted content that restricts access to specific referring domains. Setting the correct Referer header allows your server to access the content as if the request originated from an authorized page.

Origin Header

Similar to the Referer header, the Origin header is checked by some sources for access control. This is particularly common with modern web APIs and CDN configurations that use origin-based access policies.

Extra FFmpeg Options

For sources that require special handling, you can pass additional FFmpeg command-line options. Common uses include:

• -reconnect 1: Automatically reconnect if the source connection drops
• -reconnect_streamed 1: Reconnect even for streamed content (not just files)
• -reconnect_delay_max 5: Maximum delay between reconnection attempts
• -timeout 5000000: Connection timeout in microseconds
• -rtsp_transport tcp: Force RTSP to use TCP instead of UDP (more reliable through firewalls)

Choosing the Right Input Protocol

Selecting the correct protocol depends on your source type and network conditions:

• IP cameras and surveillance systems: Use RTSP — it is their native protocol and provides the most reliable connection
• Web-based sources and CDN content: Use HTTP/HTTPS — standard web delivery with broad compatibility
• Existing streaming platforms: Use HLS — pull their output playlist directly
• Remote live contribution over internet: Use SRT — its error correction handles unreliable connections gracefully
• Encoder software (OBS, Wirecast, vMix): Use RTMP — universal encoder support on port 1935
• Audio sources (radio): Use HTTP — compatible with Shoutcast and Icecast streams

Protocol Comparison

Here is a side-by-side comparison of the key characteristics of each protocol:

• RTSP — Latency: Low (1-2s) | Reliability: Good on LAN | Security: Basic auth | Device Support: IP cameras, DVRs, NVRs
• HTTP/HTTPS — Latency: Variable (2-30s) | Reliability: Excellent | Security: TLS encryption | Device Support: Universal web
• HLS — Latency: High (10-30s) | Reliability: Excellent | Security: TLS + token auth | Device Support: All modern devices
• SRT — Latency: Very Low (~120ms) | Reliability: Excellent (ARQ) | Security: AES-128/256 | Device Support: Professional encoders
• RTMP — Latency: Low (1-3s) | Reliability: Good | Security: Basic (RTMPS for TLS) | Device Support: All streaming software

For most deployments, you will use a combination of protocols: RTMP for encoder ingest, RTSP for cameras, and HLS for output delivery. As your operation grows, adding SRT for remote contribution and HTTP for web sources gives you complete flexibility to accept content from any source.