Live Streaming Push Complete Guide: RTMP/SRT/WebRTC Protocol Comparison with OBS Setup

Want to stream on YouTube but don't know how to configure OBS? Enterprise event streaming — self-hosted or cloud service? Interactive streaming latency too high? Cross-region streaming unstable? Live streaming technology is more complex than it seems. This guide covers the three major protocols, OBS configuration, server setup, and optimization tips.

Core streaming workflow

Live streaming is essentially: capture → encode → network transmission → server processing → viewer playback:

1. Capture: Camera, microphone, screen, video files
2. Encode: H.264/H.265 video + AAC audio
3. Mux: FLV (RTMP), TS (SRT), MP4 (WebRTC)
4. Push: Send to streaming server via RTMP/SRT/WebRTC
5. Server processing: Transcode (optional), record, protocol conversion (e.g., RTMP to HLS)
6. Distribution: CDN or self-hosted nodes
7. Playback: Viewers pull streams via HLS, FLV, WebRTC

Two key bottlenecks: Push-end upload bandwidth + server processing capacity. The former affects video quality, the latter affects viewer count.

Three protocols comparison

Protocol	Year	Typical latency	Packet loss resistance	Codec	Server complexity	Use case
RTMP	2002	2-5s	Average	H.264/AAC	Low	Platform standard
SRT	2017	0.5-2s	Strong	Any	Medium	Cross-region
WebRTC	2011	0.1-0.5s	Strong	VP8/VP9/H.264	High	Interactive

RTMP: Old but still mainstream

RTMP (Real-Time Messaging Protocol) was developed by Adobe for Flash. Flash is dead but RTMP lives on because:

• Mature ecosystem: YouTube, Twitch, Facebook Live — almost all platforms support RTMP
• Simple implementation: FFmpeg, OBS, XSplit support it by default
• Acceptable latency: 2-5 seconds is fine for most streaming

Drawbacks:

• TCP-based: Poor packet loss resistance, noticeable stuttering on weak networks
• No longer maintained: Adobe stopped development
• Aging ecosystem: New protocols (SRT, WebRTC) are replacing it

Conclusion: For pushing to third-party platforms, RTMP is still the first choice. For your own streaming system, consider SRT.

SRT: Low-latency with packet loss resistance

SRT (Secure Reliable Transport) is Haivision's 2017 open-source protocol, designed specifically for video streaming:

• UDP-based: Strong packet loss resistance, good on weak networks
• Low latency: 0.5-2 seconds, lower than RTMP
• Encrypted: Built-in AES-128/256 encryption
• Cross-region friendly: Stable latency over long distances

Drawbacks:

• Smaller ecosystem: Limited third-party platform support
• Requires dedicated server: SRT server software (like SRT Live Server)

Conclusion: Suitable for enterprise streaming, cross-region production, unstable networks. For daily YouTube streaming, use RTMP.

WebRTC: Ultra-low latency real-time communication

WebRTC (Web Real-Time Communication) is Google's browser real-time communication protocol:

• Extremely low latency: 0.1-0.5 seconds, the only protocol for interactive streaming
• Browser native: Chrome, Firefox, Safari, Edge — no plugins needed
• P2P capable: Small-scale streaming can be peer-to-peer, saving servers

Drawbacks:

• Complex server: Requires SFU (Selective Forwarding Unit) like Janus, mediasoup
• Fragmented ecosystem: Implementations vary slightly
• Not for mass distribution: 10,000+ viewers need specialized CDN

Conclusion: First choice for interactive streaming, co-hosting, video conferencing. For mass viewing, HLS/FLV distribution is more stable.

OBS streaming configuration

OBS Studio is the most popular open-source streaming software — free, cross-platform, powerful.

Basic setup

1. Settings → Stream:

   • Service: "Custom"
   • Server: Platform RTMP URL (e.g., YouTube: rtmp://a.rtmp.youtube.com/live2)
   • Stream Key: Platform-provided key

2. Settings → Output:

   • Output Mode: "Advanced"
   • Encoder: NVIDIA NVENC H.264 (NVIDIA GPU) > AMD HW H.264 (AMD GPU) > x264 (CPU)
   • Rate Control: CBR (constant bitrate, recommended by platforms)
   • Bitrate: 1080p 30fps → 4000 kbps (see bitrate table below)
   • Keyframe Interval: 2 (platforms require 2-second I-frames)
   • Preset: P4 (NVENC) or veryfast (x264)
   • Profile: high
   • B-frames: 2 (NVENC) or 0 (x264, some platforms require)

3. Settings → Video:

   • Base Resolution: 1920x1080 (capture resolution)
   • Output Resolution: 1920x1080 or 1280x720
   • Downscale Filter: Lanczos (high quality)
   • FPS: 30 or 60

4. Settings → Audio:

   • Sample Rate: 48 kHz
   • Encoder: AAC
   • Bitrate: 128 or 160

Streaming bitrate recommendations

Resolution/FPS	Recommended bitrate (CBR)	Minimum upload bandwidth
720p 30fps	1800-2500 kbps	4 Mbps
720p 60fps	2500-3500 kbps	5 Mbps
1080p 30fps	3500-5000 kbps	7 Mbps
1080p 60fps	4500-6000 kbps	9 Mbps
4K 30fps	8000-15000 kbps	20 Mbps
4K 60fps	12000-20000 kbps	28 Mbps

Note: Streaming bitrate should not exceed 70% of upload bandwidth, otherwise stuttering. Test upload bandwidth first with Speedtest.

FFmpeg command-line streaming

Don't want to use OBS? Stream with FFmpeg:

# Push MP4 file to RTMP server
ffmpeg -re -i input.mp4 -c:v libx264 -preset veryfast -b:v 4000k -maxrate 4000k -bufsize 8000k -pix_fmt yuv420p -g 60 -c:a aac -b:a 128k -ar 48000 -f flv "rtmp://live-push.example.com/live/streamkey"

# Push screen capture to RTMP (Linux)
ffmpeg -f x11grab -framerate 30 -video_size 1920x1080 -i :0.0 -f alsa -i default -c:v libx264 -preset veryfast -b:v 4000k -g 60 -c:a aac -b:a 128k -f flv "rtmp://live-push.example.com/live/streamkey"

# Push to SRT server
ffmpeg -re -i input.mp4 -c:v libx264 -preset veryfast -b:v 4000k -c:a aac -b:a 128k -f mpegts "srt://server.example.com:10080?streamid=live/streamkey"

Parameter explanations:

• -re: Read at real-time speed (required for streaming)
• -g 60: Keyframe interval 60 frames (2 seconds at 30fps)
• -pix_fmt yuv420p: Most compatible color space
• -f flv: RTMP uses FLV container
• -f mpegts: SRT uses MPEG-TS container

For more FFmpeg usage, see our FFmpeg Getting Started Tutorial.

Streaming server options

Option 1: Nginx-RTMP (lightweight)

Nginx + RTMP module, suitable for small-scale streaming and testing:

# nginx.conf
worker_processes auto;

events {
    worker_connections 1024;
}

rtmp {
    server {
        listen 1935;
        chunk_size 4096;
        
        application live {
            live on;
            record off;
            
            # Enable HLS
            hls on;
            hls_path /var/www/hls;
            hls_fragment 2s;
            hls_playlist_length 10s;
        }
    }
}

http {
    server {
        listen 80;
        
        location /hls {
            types {
                application/vnd.apple.mpegurl m3u8;
                video/mp2t ts;
            }
            root /var/www;
            add_header Access-Control-Allow-Origin *;
        }
    }
}

Push to rtmp://your-server/live/test, viewers pull from http://your-server/hls/test.m3u8.

For detailed setup, see our Nginx-RTMP streaming server tutorial.

Option 2: SRS (production-grade)

SRS is an open-source streaming server supporting RTMP, HLS, HTTP-FLV, WebRTC:

# Docker one-click deployment
docker run --rm -p 1935:1935 -p 8080:8080 ossrs/srs:5

# Push stream
ffmpeg -re -i input.mp4 -c copy -f flv rtmp://localhost:1935/live/test

# Playback
# RTMP: rtmp://localhost:1935/live/test
# HLS: http://localhost:8080/live/test.m3u8
# HTTP-FLV: http://localhost:8080/live/test.flv
# WebRTC: http://localhost:8080/players/whep.html?app=live&stream=test

SRS's advantages: simple configuration, excellent performance, comprehensive protocol support. Suitable for medium-large streaming operations.

Option 3: Cloud services (most convenient)

Don't want to maintain servers? Use cloud streaming services:

• International: AWS IVS, Mux, Vimeo Live Streaming
• China: Tencent Cloud Live, Alibaba Cloud Live

Advantages: one-stop service (push → transcode → distribute → player). Disadvantages: pay-per-traffic, expensive at scale.

Distribution protocol comparison

Viewer-side pull protocol choice is also important:

Protocol	Latency	Compatibility	Use case
HLS	5-30s	All	Default fallback
LL-HLS	1-2s	iOS 15+, Chrome	Low-latency streaming
HTTP-FLV	2-5s	Chrome, Firefox	Popular in China (Bilibili)
WebRTC	0.1-0.5s	Modern browsers	Interactive streaming

Chinese platforms (Bilibili, Douyu, Huya) widely use HTTP-FLV distribution — lower latency than HLS, better compatibility than WebRTC. International platforms (YouTube, Twitch) primarily use HLS and LL-HLS.

For HLS principles, see our M3U8 file complete guide.

Streaming optimization tips

1. Encoder selection

• NVIDIA GPU users: NVENC H.264 (GPU encoding, low CPU usage)
• AMD GPU users: AMD AMF H.264
• Intel iGPU users: Intel QuickSync H.264
• No hardware acceleration: x264 encoder, use veryfast preset for speed/quality balance

2. Key parameters

• Keyframe interval (GOP size): 2 seconds (60 frames at 30fps, 120 at 60fps)
• B-frames: 2 for NVENC, 0 for x264 (some platforms require)
• Profile: high (good compatibility) or main (lower latency)
• Rate control: CBR (recommended for streaming) or VBR (for VOD)

3. Network optimization

• Use wired network, avoid WiFi
• Upload bandwidth at least 1.5x streaming bitrate
• Enable QoS on router, prioritize streaming traffic
• Close background downloads, cloud sync, other bandwidth-using apps

4. Quality improvement

• Don't set bitrate too low, see bitrate table
• Use yuv420p not yuv444p (compatibility)
• Disable OBS "Delay" option (unless needed)
• Use Lanczos downscale filter, clearer than Bilinear

Common issues

Issue	Cause	Solution
Stream stuttering	Insufficient upload bandwidth	Test speed, lower bitrate to within 70% of bandwidth
Grayish video	Wrong color space	Add -pix_fmt yuv420p
High latency	Platform defaults to HLS	Use HTTP-FLV or LL-HLS
Stream disconnects	Network instability	Enable OBS "Auto-Reconnect"
Video stutters but bitrate normal	High CPU usage	Use NVENC, lower preset
Audio/video desync	Inconsistent encoding buffers	Check audio sample rate (48kHz)
Keyframe warnings	Wrong keyframe interval	Set to 2 seconds

Summary

Three streaming protocols each have their place: RTMP is the platform push standard, SRT for professional cross-region transmission, WebRTC for ultra-low latency interaction. For daily YouTube/Twitch streaming, RTMP is fine. For professional cross-region production, consider SRT. For interactive co-hosting, WebRTC is essential.

OBS key parameters to remember: hardware encoder, CBR rate control, 2-second keyframe interval, yuv420p color space, bitrate per recommendation table. For streaming servers: Nginx-RTMP for small scale, SRS or cloud services for production.

Quick reference:

• Protocol selection: RTMP (platforms), SRT (cross-region), WebRTC (interactive)
• Bitrate reference: 1080p 30fps → 4000 kbps
• Key parameters: Hardware encoder + CBR + 2s keyframes + yuv420p
• Server selection: Nginx-RTMP for testing, SRS for production

References

• RTMP — Wikipedia
• SRT protocol official site
• WebRTC — Wikipedia
• OBS Studio official site
• SRS GitHub